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