crt0 formalization

[Joel Sherrill]

Jeff Johnston wrote:
> 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.
>

Don't hold up newlib 1.15.0 for this.  Put it where ever they want and 
move on. 
> 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.
>
Unless someone has a good case against it, I think that's what I am 
proposing.  crt[in] shouldn't be in
newlib at all and should only be in libgloss if there is a demonstrable 
requirement to be board specific.
So far, no one has produced a case that requires crt[in] to be anywhere 
but gcc.

--joel

> -- Jeff J.