From owner-freebsd-bugs Wed Oct 18 7:27:20 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from web1703.mail.yahoo.com (web1703.mail.yahoo.com [128.11.23.214]) by hub.freebsd.org (Postfix) with SMTP id 375BC37B4FE for ; Wed, 18 Oct 2000 07:27:16 -0700 (PDT) Received: (qmail 18386 invoked by uid 60001); 18 Oct 2000 14:27:15 -0000 Message-ID: <20001018142715.18385.qmail@web1703.mail.yahoo.com> Received: from [202.101.165.61] by web1703.mail.yahoo.com; Wed, 18 Oct 2000 07:27:15 PDT Date: Wed, 18 Oct 2000 07:27:15 -0700 (PDT) From: Yifeng Xu Subject: Re: gnu/20966: binutils break C++ in GCC 2.95.x and GCC-current To: freebsd-bugs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I also report the problem a few months ago, On FreeBSD 4.x, some C++ programs can work under Linux but not FreeBSD, example code: tst.cpp or tst.c ------------------ #include void f() __attribute((__constructor__)); int i; void f() { i = 1; } int main(int argc, char *argv[]) { printf("%d\n", i); return 0; } $ cc -o tst tst.c $ ./tst 1 $ c++ -o tst tst.cpp 0 $ why have different result? Alexander, please give me an answer. Regards, XuYifeng ----- Original Message ----- From: Alexander N. Kabaev To: Cc: ; Peter Wemm Sent: Wednesday, October 18, 2000 12:33 PM Subject: Re: gnu/20966: binutils break C++ in GCC 2.95.x and GCC-current > > > 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 __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message