Date: Wed, 18 Oct 2000 07:27:15 -0700 (PDT) From: Yifeng Xu <websoft@yahoo.com> To: freebsd-bugs@freebsd.org Subject: Re: gnu/20966: binutils break C++ in GCC 2.95.x and GCC-current Message-ID: <20001018142715.18385.qmail@web1703.mail.yahoo.com>
next in thread | raw e-mail | index | archive | help
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 <stdio.h>
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 <kabaev@mail.ru>
To: <freebsd-gnats-submit@FreeBSD.ORG>
Cc: <freebsd-bugs@FreeBSD.ORG>; Peter Wemm
<peter@yahoo-inc.com>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001018142715.18385.qmail>