[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Automatic manager initialisation



On Fri, 2004-06-04 at 07:36, Chris Johns wrote:
> 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 ?

Basically yes.

> 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 ?
I do, but I have never used it and I don't know if others have done.

> > 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 ?
Theoretically, yes, but ... 

> > * 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.

No it doesn't. 

>  The object file may be bigger as 
> ELF does contain extra information but this should be stripped when a 
> binary image is created.
Try building the RTEMS samples for the gensh1 and
sh-rtems/sh-rtemself/sh-rtemscoff using the same
compiler/binutils/newlib/rtems versions and you will trip this issue.
SH-ELF for some reasons (unknown to me) is bigger.

Ralf