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
