crt0 formalization

[Joel Sherrill]

Jeff Johnston wrote:
> Joel Sherrill wrote:
>> jschopp wrote:
>>>> I'm confused.  Which way are you suggesting it be done for the spu?
>>>
>>> In newlib.
>>
>> If I am reading the patch correctly, you put it in
>> libgloss which is essentially a Board Support Package
>> for no operating system.  Thus it will only be available
>> for the spu-elf target.
>>
>> I don't think that's the best place for it since
>> this means that that no spu-OS (not spu-OBJECT_FORMAT)
>> target will pick it up there.
>> In fact, I am disappointed that the other four targets
>> have it in libgloss. It may be allowed but it doesn't
>> seem like the best choice.  I know if there were an RTEMS
>> port to any of the targets which have the crt[in] in
>> libgloss, it would have to be copied to somewhere else for
>> XXX-rtems to have access to it.
>>
>
> I've been sick for the last two days so forgive my silence.
>
> The reason libgloss is used over newlib is that when something gets 
> put in newlib, it becomes difficult to override if one needs to change 
> it for a particular board.
>
> If the code in question will be universal across all spu boards and 
> OSes that will run on spu, then it can go unconditionally in 
> libc/machine/spu.
>
> 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?
>
Yes but:

 + Is there another target that has crt[in] in newlib?  I don't see any 
in 1.14.0.
 + Why should any crt[in] code in libgloss if it is not board 
specific?   In the targets
    cited, I did see crt[in] code in gcc for them.

I guess I have always viewed this as tied to how gcc generates code for 
ctors and dtors
so it is a function or the gcc target selected.  If someone changed how 
the target did
ctor/dtors in gcc, would they think of hunting down generic crt[in] code 
in newlib or libgloss?

If it really is board specific, then libgloss is the right location.  
But if it isn't then isn't it
more tightly coupled with gcc than newlib or libgloss?

I'm not trying to be difficult. Things are complicated enough without 
adding a 3rd location
for crt[in] -- especially if it turns out the ones already in libgloss 
are not board specific and
I don't see any code in the ones currently in libgloss that looks board 
specific. 
>> RTEMS doesn't use libgloss so I need to ask: does
>> libgloss get built multilib?  If not, that could be
>> another potential downside with putting them there.
>>
>
> Yes, libgloss gets built multilib.
>
Good. One thing not to worry about. :)

> -- Jeff J.