Re: crt0 formalization

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

jschopp wrote:
> > > Since this is SPU specific, I assume it is correct for that.  But I
> > > wonder why crt[in].S are included
> > > in newlib.  Normally they are in gcc.
> >
> > I'd like to know the reason why crt[in] are in newlib.
> > The SPU gcc (at least FSF spu-gcc) also has crt[in],
> > and they are quite similar to newlib's ones.
> >
> > Joel (jschopp), could you explain about them ?
>
> I belive I've caused some confusion.
>
> According to GCC internals (14.21.5 How initialization functions are 
> handled):
> "The prologue of a function (__init) appears in the .init section of 
> 'crti.o'; the epilogue appears in 'crtn.o'. Likewise for the function 
> __fini in the .fini section. Normally these files are provided by the 
> operating system or by the GNU C library, but are provided by GCC for 
> a few targets."
>
> It also seems that the following targets already provide crt[in] in 
> libgloss: crx, cris, m32c, xstormy16.  It seems logical to me that 
> making the distiction at "crt[in] - system init code provided by the 
> system library"  vs. "crt{begin,end} - compiler init code provided 
> with GCC" makes sense.
So 4 targets put crt[in] in libgloss.  I didn't know that. :)  
Unfortunately, I think none of those are considered primary or secondary
targets in gcc so may or may not be the best examples.

There are 12 targets which include crt[in] or equivalent in gcc (using 
just a quick find):

   arm bfin fr30 h8300 ia64 m68k mcore mips mmix mt sh sparc xtensa

All are certainly not primary platforms for gcc so I wouldn't consider 
all of them great examples but some
are primaries for gcc so would could hope.

FWIW it is certainly easy to share crti/n across different OSes.  In 
fact, I was reminded while doing this
that RTEMS uses the same one as Solaris on the i386 and SPARC.  And uses 
the EABI ones on PowerPC.
My quick reading of the SPU versions looked like they were OS 
independent also.
> Ben (ccd) is changing the FSF spu-gcc to this model.  It makes a lot 
> of sense to me, so I forwarded on a patch to make newlib match Ben's 
> submission on the gcc side.  We've tested both the gcc and newlib with 
> these changes in our SDK 2.0 and it seems to work quite well.  I don't 
> have particularly strong opinions either way.  So, if there are valid 
> technical objections please let me know.  More importantly please let 
> Ben know.
I'm confused.  Which way are you suggesting it be done for the spu?

--joel sherrill
> -Joel