Automatic manager initialisation

[Chris Johns]

Ralf Corsepius wrote:
> On Fri, 2004-06-04 at 04:48, Chris Johns wrote:
> 
> IMHO, switching to ELF is a double sided sword. On one hand, it provides
> nice features and is way better supported by the toolchains than other
> object formats.
> On the other hand, I would prefer RTEMS not to be based on _any_ object
> format specific details, because this could prevent users from porting
> RTEMS to specific targets or from using external libs or tools with
> RTEMS. 

I agree, but it should not stop us from conditionally allowing new 
features that benefit other users.

Does the gcc '__attribute((section("xxxx")))' extension work for COFF ?

If we can autoconf test for the feature it can be enabled automatically. 
If the object format does not support the attribute section extension in 
gcc then the current scheme can be used.

Can I assume you do not build the networking stack for SH COFF targets ?

> E.g. the main reasons why SH users might prefer COFF over ELF:
> * The traditional object format for the SHes had been COFF. Therefore
> they might want to continue using commercial (COFF-)libs or tools with
> RTEMS.

Can objcopy copy the COFF lib to ELF ?

> * On the SHes, the size of ELF-objects is larger than the size of COFF
> objects. On low-end targets, such as SH1/SH2s this increase in size is
> critical. (Building the RTEMS samples w/ sh-rtemself fails because of
> hitting the memory limits of this BSP (The memory limits are the
> real-world settings of our old AMOS boards)

I am not sure I follow. I would have expected gcc to generate the same 
code for the same release of compiler. The object file may be bigger as 
ELF does contain extra information but this should be stripped when a 
binary image is created.

-- 
  Chris Johns