[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Automatic manager initialisation
- Date: Fri, 04 Jun 2004 11:57:04 +0200
- From: ralf_corsepius at rtems.org (Ralf Corsepius)
- Subject: 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 ?
> 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.