This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: crt0 formalization
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Andrew_Pinski at PlayStation dot Sony dot Com
- Cc: Jeff Johnston <jjohnstn at redhat dot com>, Kazunori Asayama <asayama at sm dot sony dot co dot jp>, Ben Elliston <elliston at au1 dot ibm dot com>, jschopp <jschopp at austin dot ibm dot com>, newlib at sources dot redhat dot com
- Date: Thu, 07 Dec 2006 12:22:25 -0600
- Subject: Re: crt0 formalization
- References: <OFFF5DDE83.D15C510B-ON8825723D.006335D6-8825723D.00639DF1@playstation.sony.com>
Andrew_Pinski@PlayStation.Sony.Com wrote:
newlib-owner@sourceware.org wrote on 12/07/2006 08:59:51 AM:
Otherwise, I suggest we leave the patch as-is and then also add the code
to libc/machine/spu where configure tells it to be added or not (e.g.
spu-*-rtems, add the two files). Seem reasonable?
SPU-elf is really a special target, it can never be used alone, in that it
needs
another target to communicate with (in all cases right now it is either a
powerpc64-linux
or powerpc-linux or the PS3 game OS). When someone goes out of their way
to create a
powerpc64-*-rtems, they most likely will also use the same interface for
the SPU as it is
a target independent interface.
I must be missing something in this. I understand the architectural
relationship between the PowerPC and SPUs. But are you saying spu-elf is
the only target that will ever make sense to use for an SPU because you
would really run your choice of OS on the PowerPC side so that's the
target that would vary?
If I understood you correctly, it doesn't justify putting crt[in] in
libgloss. It just means that
there is only one valid spu target and it always uses the same crt[in].
That seems to me that
it makes gcc the more likely place to put it since it won't be tied to
any particular C library.
Believe it or not, I'm not picking on the spu specifically. I haven't
heard one convincing
argument for crt[in] not being in gcc for any target yet. The only
support for them being
is libgloss is some documentation and 4 targets that did it with no
obvious justification
looking at the code. No clearly board dependent example crt[in] has
been produced.
For all I know the documentation was changed to account for the 4 being
in libgloss
and those weren't questioned when they were put in.
I hate to keep dragging this out. I just remain unconvinced.
--joel
Thanks,
Andrew Pinski