This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: crt0 formalization


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]