http://sourceware.org/bugzilla/show_bug.cgi?id=12629
Summary: lto, linker-plugin and optimization clutter the stack trace when using gold Product: binutils Version: 2.21 Status: NEW Severity: critical Priority: P2 Component: gold AssignedTo: i...@airs.com ReportedBy: vincenzo.innoce...@cern.ch Created attachment 5348 --> http://sourceware.org/bugzilla/attachment.cgi?id=5348 an header file, three compilation units, a script to source that will produce several shared libraries and executable I submitted this bug report to gcc first http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48384 It actually turned out to be a regression of gold w.r.t. standard bfd "ld". I'm not yet sure if the problem is on the binutil or gcc side. Below is a copy of my original post to gcc- bugzilla Please refer to gcc bug report for the more details. ----------------------------------------------------- I'm testing lto and the linker-plugin within shared libraries. Results using hidden visibility are very encouraging. Unfortunately the combination of even mild optimization (O2) and -flto -fuse-linker-plugin seems to clutter the stack-trace. This can be easily shown in gdb. It makes also instrumentation tools, that rely on stack trace, to either crash or produce wrong results. I'm using gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-gold=yes --enable-lto --with-fpmath=avx Thread model: posix gcc version 4.6.1 20110325 (prerelease) (GCC) GNU gold (GNU Binutils 2.21) 1.10 Linux vinavx0.cern.ch 2.6.32-71.14.1.el6.x86_64 #1 SMP Thu Jan 13 12:03:40 CET 2011 x86_64 x86_64 x86_64 GNU/Linux glibc.x86_64 2.12-1.7.el6_0.4 GNU gdb (GDB) Red Hat Enterprise Linux (7.1-29.el6_0.1) In the attachment there are the four files of my simple test (a long loop and a seg-fault) and a script that builds various versions just compare g++ -g -DHIDDEN go.cc foo.cc -flto -fuse-linker-plugin -fPIC -shared -o libfoo_hltog.so g++ -g -DHIDDEN main.cc -flto -fuse-linker-plugin -L./ -lfoo_hltog -o t_hltog with g++ -O2 -g -DHIDDEN go.cc foo.cc -flto -fuse-linker-plugin -fPIC -shared -o libfoo_hltog2.so g++ -O2 -g -DHIDDEN main.cc -flto -fuse-linker-plugin -L./ -lfoo_hltog2 -o t_hltog2 the first looks ok, (the segmentation fault deferencing a zero pointer is intentional) the latter in gdb will produce (gdb) run Starting program: /afs/cern.ch/user/i/innocent/public/ctest/lto/t_hltog2 Program received signal SIGSEGV, Segmentation fault. go (j=Cannot access memory at address 0x0 ) at go.cc:5 5 j+= foo(h); Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.7.el6_0.4.x86_64 (gdb) where #0 go (j=Cannot access memory at address 0x0 ) at go.cc:5 #1 0x00000000000003e8 in ?? () #2 0x42c800004232ee1f in ?? () #3 0x0000000000000000 in ?? () (gdb) run 2 The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /afs/cern.ch/user/i/innocent/public/ctest/lto/t_hltog2 2 ^C Program received signal SIGINT, Interrupt. 0x0000003ff6207ebd in __ieee754_asin () from /lib64/libm.so.6 (gdb) where #0 0x0000003ff6207ebd in __ieee754_asin () from /lib64/libm.so.6 #1 0x0000003ff6224842 in asin () from /lib64/libm.so.6 #2 0x00007ffff7ffb6aa in bar (j=20000001, h=0x0) at foo.cc:14 #3 go (j=20000001, h=0x0) at go.cc:4 #4 0x0000000000989680 in ?? () #5 0x3f8000003f800001 in ?? () #6 0x0000000000000000 in ?? () (gdb) in more complex applications with multiple shared libraries things gets much more confused with "??" all over the srack-trace -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils