Re: crt{i,n}.o

[Geoff Keating <geoffk at cygnus dot com>]

> Date: Tue, 24 Oct 2000 13:36:27 -0700
> From: "David O'Brien" <obrien@FreeBSD.org>
> Cc: gcc@gcc.gnu.org
> Reply-To: obrien@FreeBSD.org

> On Tue, Oct 24, 2000 at 12:50:25PM -0700, Geoff Keating wrote:
> > > Since GCC provides its own crtbegin.o and crtend.o, why doesn't it
> > > provide its own crti.o and crtn.o? 
> > 
> > crti.o and crtn.o are, by definition, provided by the target system.

Oops!  I was wrong.  GCC often does provide its own crti.o and crtn.o.

> Why isn't crt{begin,end}.o by definition not provided by the target
> system?  (I don't have full ELF ABI specs)

It is (assuming that you really meant the double negative).

GCC needs its own place to have hooks, and this was it.

The ABI doesn't specify any of this.  crt0.o, crt1.o, crti.o, crtn.o,
are historical names for various files which are supplied by the OS,
although GCC often supplies them if the OS is deficient.  crtbegin.o
and crtend.o are GCC inventions, they are to allow GCC to _not_
replace the OS's supplied crt[in].o files as replacing those files
often causes trouble.

The SVR4 ABI doesn't need to specify it.  Instead it specifies the
startup environment, and what DT_INIT and DT_FINI mean, and then apps
or compilers can do whatever they want.  You can write a
crt1.o, crti.o, and crtn.o for any strict SVR4 environment without
needing to know anything more about the OS.

The real purpose of the crti.o/crtbegin.o separation is so that GNU
libc can provide one, and GCC can provide the other.  This permits the
GNU libc maintainers to change the way profiling is done without
having to synchronize releases with the compiler.  Profiling, of
course, is not covered by the SVR4 ABI, like debugging, because it's a
feature of the development environment not of the OS and it doesn't
have to be portable.

> > What assumption?
> 
> FreeBSD's 4.1.1's /usr/lib/crt{i,n} doesn't have the bits GCC's crtstuff
> wants:
> 
>     	.section .init,"ax",@progbits
>     	.align	4
>     	.globl	_init
>     	.type	_init,@function
>     _init:
> 
>     	.section .fini,"ax",@progbits
>     	.align	4
>     	.globl	_fini
>     	.type	_fini,@function
>     _fini:
> 
> and
> 	.section .init,"ax",@progbits
> 	ret
> 
> 	.section .fini,"ax",@progbits
> 	ret
> 
> ie, that _init and _fini are registered and return at the end.

So what _do_ you have in crt[in].o?  This is their entire contents
under (at least powerpc) Linux, except for a little bit of code
to support profiling.  It's also their entire contents under Solaris,
see gcc/config/sparc/sol2-ci.asm.

> We have our own /usr/lib/crt{begin,end}.o that works fine with TenDRA
> (another C/C++ compiler).

Solaris has its own /opt/SUNWspro/SC3.0.1/lib/crt[1in].o which
presumably works fine with their compiler.  They don't need a
crt{begin,end}.o because they put all their compiler-specific stuff in
crt*.o.

> However, I've been pushed to abandon our native crt{begin,end}.o
> because G++ is best supported by it (ie, G++ assumes things are done
> the way crtstuff.c does them).  Thus stock builds of GCC 2.97 have
> broken exceptions for instance.

Yes.  To be precise, G++ assumes that you are using the crtbegin.o
that it provides, in much the same way it assumes you are using the
'g++' executable provided with the compiler not calling cc1plus by
hand.

I think you really have two sane choices:

1. Pretend that the BSDs come with no native compiler, like Solaris.
   Have GCC provide its own crt[1in].o files.

2. Have GCC fit into the BSD systems the way it fits into systems that
   use GNU libc, like Linux.  Have the libc provide a crt[1in].o file
   that does what GCC expects.

-- 
- Geoffrey Keating <geoffk@cygnus.com>