crt0 formalization

[Jeff Johnston]

Joel Sherrill wrote:
> 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

I would like to stress that newlib 1.15.0 is coming due.  If the patch 
is accepted as-is, there is nothing to prevent the crti/n files from 
being added to gcc later (and later removed from libgloss).  If someone 
from the spu group wants to stand up and agree to make a gcc patch, I'll 
be happy to take the files out of the patch now and check the remainder 
in.

If this is attempting to evolve into a policy regarding what gcc must 
provide on their side of the fence, then I believe that it should 
probably move to the gcc list.

-- Jeff J.