public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "vincenzo.innocente at cern dot ch" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/48423] New: crash when using lto, linker plugin with bfd ld Date: Sun, 03 Apr 2011 11:27:00 -0000 [thread overview] Message-ID: <bug-48423-4@http.gcc.gnu.org/bugzilla/> (raw) 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: unassigned@gcc.gnu.org ReportedBy: vincenzo.innocente@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)
next reply other threads:[~2011-04-03 11:27 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-04-03 11:27 vincenzo.innocente at cern dot ch [this message] 2011-04-03 17:04 ` [Bug lto/48423] " hjl.tools at gmail dot com 2011-04-03 17:34 ` vincenzo.innocente at cern dot ch 2011-04-03 18:06 ` hjl.tools at gmail dot com 2011-04-03 20:05 ` vincenzo.innocente at cern dot ch 2011-05-11 22:07 ` paolo.carlini at oracle dot com 2011-05-11 22:51 ` hjl.tools at gmail dot com 2011-05-14 18:38 ` vincenzo.innocente at cern dot ch 2012-05-07 12:31 ` rguenth at gcc dot gnu.org 2012-05-07 13:04 ` vincenzo.innocente at cern dot ch 2012-05-07 13:22 ` rguenth at gcc dot gnu.org 2012-05-09 13:29 ` vincenzo.innocente at cern dot ch
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-48423-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).