http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48423
Summary: crash when using lto, linker plugin with bfd ld
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
I'm continuing my experiments with lto, linker-plugins and visibility.
I've now built a simple example of a typical plugin architecture (similar to
the one in use in my project)
with a base class in one library and derived classes in run-time loadable
libraries.
I get "ld" warnings and a crash in the attached examples when linking with
ld -v
GNU ld (GNU Binutils) 2.21
it compiles, links and runs fine with
ld -v
GNU gold (GNU Binutils 2.21) 1.10
just download it and
source makeLinux
ld: warning: type and size of dynamic symbol `typeinfo for Base' are not
defined
ld: warning: type and size of dynamic symbol `typeinfo for Base' are not
defined
and then
gdb exFactory
GNU gdb (GDB) 7.1
...
Get D
Program received signal SIGSEGV, Segmentation fault.
0x0000000000401826 in get (c=<value optimized out>) at exFactory.cpp:27
27 (*bp).hi();
(gdb) where
#0 0x0000000000401826 in get (c=<value optimized out>) at exFactory.cpp:27
#1 0x0000000000401984 in main () at exFactory.cpp:39
one can activate the construction of a static object in the library that
actually causes the crash to see it
crashing even in the library itself
source makeLinux -DSHELLO
ld: warning: type and size of dynamic symbol `typeinfo for Base' are not
defined
ld: warning: type and size of dynamic symbol `typeinfo for Base' are not
defined
[vinavx0] ~/w1/ltoCrash $ gdb exFactory
Get D
break point hook
hello D
who in D
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff78cce68 in D::who (this=<value optimized out>, b=...) at Base.h:19
19 return ii();
(gdb) where
#0 0x00007ffff78cce68 in D::who (this=<value optimized out>, b=...) at
Base.h:19
#1 0x00007ffff78cd150 in __static_initialization_and_destruction_0 () at
helloD.cc:17
#2 global constructors keyed to 65535_0_ccyFVIjt.o () at helloD.cc:25
#3 0x00007ffff78ccb85 in __do_global_ctors_aux () from ./plugD.so
#4 0x00007ffff78cc8fb in _init () from ./plugD.so
#5 0x0000003f00000000 in ?? ()
#6 0x0000003ff520e3b5 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#7 0x0000003ff5212b21 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#8 0x0000003ff520e016 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#9 0x0000003ff521236a in _dl_open () from /lib64/ld-linux-x86-64.so.2
#10 0x0000003ff5a00f66 in dlopen_doit () from /lib64/libdl.so.2
#11 0x0000003ff520e016 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#12 0x0000003ff5a0129c in _dlerror_run () from /lib64/libdl.so.2
#13 0x0000003ff5a00ee1 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2
#14 0x00000000004017f1 in magic (c=...) at exFactory.cpp:12
#15 get (c=...) at exFactory.cpp:23
#16 0x0000000000401984 in main () at exFactory.cpp:39
(one can use "bhook" to set a breakpoint just before this crash)
as the program runs w/o errors when linked with gold I'm not sure on which side
(gcc or binutil)
the problem is.
Any hint even on how to work-around this issue would be appreciated as gold, at
the moment,
is also not fully usable with linker-plugins as it produces clobbered
stacktrace
(see bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48384)
