Re: crt0 formalization

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Joel Sherrill wrote:

> 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?

Actually, as I see it, crt[in] are *not* supposed to be GCC-specific
at all.  GCC comes with its own set of files, crtbegin.o and crtend.o,
which handle all the GCC related ctor/dtor issues.  Those files are
*hooked into* a system-wide init/fini mechanism provided the system,
typically the system library -- at least that's the setup on all
glibc-based systems: crt[in] come with glibc, crtbegin/end come with
GCC.

I thought that made sense since the crt[in] mechanism itself is
driven by the entry point startup file crt0, which should also come
from the system library.

So, when I originally proposed cleaning up the current SPU startfile
situation, I simply wanted to mimic existing usage.  I've now learned
that apparently on many embedded targets crt[in] are also provided
by GCC.  I'm not quite sure what the reasoning for this was, and why
this issue should be handled differently between newlib and glibc ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com