This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: crt0 formalization


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.

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.

-Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]