Bug 12629 - lto, linker-plugin and optimization clutter the stack trace when using gold
Summary: lto, linker-plugin and optimization clutter the stack trace when using gold
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: gold (show other bugs)
Version: 2.21
: P2 critical
Target Milestone: ---
Assignee: Ian Lance Taylor
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-01 08:00 UTC by Vincenzo Innocente
Modified: 2011-06-30 00:52 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
an header file, three compilation units, a script to source that will produce several shared libraries and executable (801 bytes, application/x-gzip)
2011-04-01 08:00 UTC, Vincenzo Innocente
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vincenzo Innocente 2011-04-01 08:00:30 UTC
Created attachment 5348 [details]
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
Comment 1 Sourceware Commits 2011-06-30 00:50:17 UTC
CVSROOT:	/cvs/src
Module name:	src
Changes by:	ian@sourceware.org	2011-06-30 00:50:13

Modified files:
	gold           : ChangeLog object.cc object.h 

Log message:
	PR gold/12629
	* object.cc (Sized_relobj_file::layout_section): Change shdr
	parameter to be const.
	(Sized_relobj_file::layout_eh_frame_section): New function, broken
	out of do_layout.
	(Sized_relobj_file::do_layout): Defer .eh_frame sections if
	appropriate.  Call layout_eh_frame_section.
	(Sized_relobj_file::do_layout_deferred_sections): Handle .eh_frame
	sections.
	* object.h (class Sized_relobj_file): Update declarations.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/ChangeLog.diff?cvsroot=src&r1=1.778&r2=1.779
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/object.cc.diff?cvsroot=src&r1=1.144&r2=1.145
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/object.h.diff?cvsroot=src&r1=1.111&r2=1.112
Comment 2 Ian Lance Taylor 2011-06-30 00:52:50 UTC
I committed a patch for this to the gold development sources.  Thanks for the good test case.