question of __RedBoot_IDLE_TAB__?

[Billking]

hello everybody: I port redboot to a board based ARM7TDMI architecture,but I found pretty confused about this classs struct "__RedBoot_IDLE_TAB__",because it have not been initialised.But when running redboot it pricesely pointer to net_io_test,how does redboot do it. any explanation apprieciate! best regard!

[Andrew Lunn-2]

On Thu, Jan 31, 2008 at 12:16:50AM -0800, Billking wrote:
>
> hello everybody:
> I port redboot to a board based ARM7TDMI architecture,but I found pretty
> confused about this classs struct "__RedBoot_IDLE_TAB__",because it have not
> been initialised.But when running redboot it pricesely pointer to
> net_io_test,how does redboot do it.
> any explanation apprieciate!

Its magic!

Well, its just not common C. It uses the GNU linker and some GNU
extensions in gcc.

Take a look at:

hal/common/current/include/hal_tables.h

        Andrew



--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[Grant Edwards]

On 2008-01-31, Andrew Lunn <andrew@...> wrote:

> On Thu, Jan 31, 2008 at 12:16:50AM -0800, Billking wrote:
>>
>> hello everybody:
>> I port redboot to a board based ARM7TDMI architecture,but I found pretty
>> confused about this classs struct "__RedBoot_IDLE_TAB__",because it have not
>> been initialised.But when running redboot it pricesely pointer to
>> net_io_test,how does redboot do it.
>> any explanation apprieciate!
>
> Its magic!

Darned near.

> Well, its just not common C. It uses the GNU linker and some GNU
> extensions in gcc.
>
> Take a look at:
>
> hal/common/current/include/hal_tables.h

It's just plain brilliant.  I've used that scheme on several
other (non-eCos) projects, and it _very_ neatly solves the
problem of keeping modules isolated while allowing an easy way
for the modules to provide various "entry points" for the main
system to use without the main system actually having to be
aware at compile time of what modules are going to be present
at run time.

--
Grant Edwards                   grante             Yow! An Italian is COMBING
                                  at               his hair in suburban DES
                               visi.com            MOINES!


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[Gary Thomas]

Grant Edwards wrote:

> On 2008-01-31, Andrew Lunn <andrew@...> wrote:
>> On Thu, Jan 31, 2008 at 12:16:50AM -0800, Billking wrote:
>>> hello everybody:
>>> I port redboot to a board based ARM7TDMI architecture,but I found pretty
>>> confused about this classs struct "__RedBoot_IDLE_TAB__",because it have not
>>> been initialised.But when running redboot it pricesely pointer to
>>> net_io_test,how does redboot do it.
>>> any explanation apprieciate!
>> Its magic!
>
> Darned near.
>
>> Well, its just not common C. It uses the GNU linker and some GNU
>> extensions in gcc.
>>
>> Take a look at:
>>
>> hal/common/current/include/hal_tables.h
>
> It's just plain brilliant.  I've used that scheme on several
> other (non-eCos) projects, and it _very_ neatly solves the
> problem of keeping modules isolated while allowing an easy way
> for the modules to provide various "entry points" for the main
> system to use without the main system actually having to be
> aware at compile time of what modules are going to be present
> at run time.
>

Thanks (my idea, inspired by the Linux kernel).

The sad part is that for this to work, the module(s) have to
be available to the linker (hence libextras.a) which sort of
criples the ability of the selective linking process.


--
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[Grant Edwards]

On 2008-01-31, Gary Thomas <gary@...> wrote:

>>> hal/common/current/include/hal_tables.h
>>
>> It's just plain brilliant.  I've used that scheme on several
>> other (non-eCos) projects, and it _very_ neatly solves the
>> problem of keeping modules isolated while allowing an easy way
>> for the modules to provide various "entry points" for the main
>> system to use without the main system actually having to be
>> aware at compile time of what modules are going to be present
>> at run time.
>>
>
> Thanks (my idea, inspired by the Linux kernel).
>
> The sad part is that for this to work, the module(s) have to
> be available to the linker (hence libextras.a) which sort of
> criples the ability of the selective linking process.

That's never been an issue for any of the projects where I've
used it.

It allows me to have an easy way to build two different
versions of an application (with different feature sets) by
simply linking a different set of object files.  You don't have
to make any of a module's symbols visible outside the modules
and you don't have to edit an include file and then recompile
the "main" module to let it know that a different set of
modules are now included.  

It also makes it easy to comment out or "ifdef" out debugging
or diagnostic features without having to also comment out calls
to them in other modules.

--
Grant Edwards                   grante             Yow! I'm also against
                                  at               BODY-SURFING!!
                               visi.com            


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[Billking]

thank you all
to this issue,I have debugged this struct
but to my surprise,I observed a absolutely address would be shared by two function
like this address is dynamic.
I have been read the hal_tables.h,and digest the ARM assembler.
but still I have no idea.
more detail appreciated

Grant Edwards wrote:

On 2008-01-31, Gary Thomas <[e-mail]> wrote:

>>> hal/common/current/include/hal_tables.h
>>
>> It's just plain brilliant.  I've used that scheme on several
>> other (non-eCos) projects, and it _very_ neatly solves the
>> problem of keeping modules isolated while allowing an easy way
>> for the modules to provide various "entry points" for the main
>> system to use without the main system actually having to be
>> aware at compile time of what modules are going to be present
>> at run time.
>>
>
> Thanks (my idea, inspired by the Linux kernel).
>
> The sad part is that for this to work, the module(s) have to
> be available to the linker (hence libextras.a) which sort of
> criples the ability of the selective linking process.

That's never been an issue for any of the projects where I've
used it.

It allows me to have an easy way to build two different
versions of an application (with different feature sets) by
simply linking a different set of object files.  You don't have
to make any of a module's symbols visible outside the modules
and you don't have to edit an include file and then recompile
the "main" module to let it know that a different set of
modules are now included.  

It also makes it easy to comment out or "ifdef" out debugging
or diagnostic features without having to also comment out calls
to them in other modules.

--
Grant Edwards                   grante             Yow! I'm also against
                                  at               BODY-SURFING!!
                               visi.com            


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[Steve West-4]

Hello,
    I used to be able to build 1386 projects with asserts on under Cygwin.
Now that I have upgraded Cygwin to the latest the assert build fails. The
compiler seems like it is running out of memory. Any ideas on how to fix the
problem?

Steve


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss