Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Oct 2000 00:33:56 -0400 (EDT)
From:      "Alexander N. Kabaev" <kabaev@mail.ru>
To:        freebsd-gnats-submit@freebsd.org
Cc:        freebsd-bugs@freebsd.org, Peter Wemm <peter@yahoo-inc.com>
Subject:   Re: gnu/20966: binutils break C++ in GCC 2.95.x and GCC-current
Message-ID:  <XFMail.001018003356.kabaev@mail.ru>

next in thread | raw e-mail | index | archive | help

> The problem is that our crt foo is incompatable with g++'s constructor
> and thread mechanism.  In order to get g++ working at yahoo, we had
> to back out to the old crt{i,n}.o and use gcc's crt{begin,end}.o
> so that the frame hooks etc were called in the right places.

I disagree. Our custom crtbegin.c was and is indeed incompatible with DWARF2
exception unwinding method GCC is using by default, but our crt1.c, crti.S and
crtn.S were working just fine until FreeBSD started to use architecture
independent crtbegin.c implementation. Since non-system GCC versions do not use
FreeBSD crtbegin.c at all, this incompatibility does not prevent them from
working correctly.

> According to my recollection of the original AT&T/USL manuals that I
> have (in Australia) that cover ELF, toolchain, linking, abi's, etc, I
> still believe our crt{i,n}.o are broken.  We have replaced the extensible
> "linker set"-like mechanism that was part of the ELF linking defintion
> with a static _init() and _fini() function. 

All that previous versions of crti.S and crtn.S files were doing is they were
providing function prologue (function name label) and epilogue (ret
instruction) for compiler generated .init and .fini sections. The way
compiler generates .init and .fini sections is indeed similar to linker
sets. Our startup files were working OK with any version of GCC as long as
GCC .init|.fini section with all initialization calls it needs. The new platform
independent implementation does not use these sections anymore and implements
it's own _init and _fini functions instead. That is IMHO wrong not only because
it breaks GCC but also because crtbegin.o will require modification each time
GCC developers add feature which requires non-trivial initialization at startup
time. 

 Presenting .init and .fini sections as functions allows us
to call them from crt1.c right before and after _main. Alternatively, ld.so
dynamic loader could be changed to run contents of these sections at the module
load time but that way we will lose the possibility to run some other code (such
as profiling related initialization) before constructors are run. Changing
dynamic loader is not feasible at this point anyway because it will introduce
severe backwards binary compatibility problems without providing any significant
advantage.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.001018003356.kabaev>