[Bug lto/48384] lto, linker-plugin and optimization clutter the stack trace
lat at cern dot ch
gcc-bugzilla@gcc.gnu.org
Sat May 14 16:30:00 GMT 2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48384
Lassi Tuura <lat at cern dot ch> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |lat at cern dot ch
--- Comment #6 from Lassi Tuura <lat at cern dot ch> 2011-05-14 15:41:35 UTC ---
I think this is an issue I previous looked at for Vincenzo, and concluded that
LTO-generated binary has unwind info referring to the wrong ELF base section,
.eh_frame, rather than .text, completely messing up any attempt to unwind. I
don't have immediate access to the exact tool chain used for this bug report so
can't replicate the necessary info right now, but I've attached a previous
analysis I sent to Vincenzo.
If this isn't sufficient to put investigation on the right track, I'll get
together with Vincenzo next week and we will generate the necessary unwind info
dumps for the specific test case he added here before.
===
At any rate the unwind info is completely messed up. For example from "readelf
-Wwf libfoo_hlto.so" we have a claim there is a function at
pc=000007a0..0000086f.
00000020 fffffea8 0000001c FDE cie=00000008 pc=000007a0..0000086f
DW_CFA_advance_loc: 2 to 000007a2
DW_CFA_def_cfa_offset: 16
DW_CFA_offset: r12 (r12) at cfa-16
DW_CFA_advance_loc: 4 to 000007a6
DW_CFA_def_cfa_offset: 24
[...]
But the only function of any significance in that library is not at that
address, as shown by "objdump -d libfoo_hlto.so". The FDE program looks correct
otherwise, just is at wrong address.
0000000000000640 <_Z2goiPKi>:
640: 41 54 push %r12
642: 49 89 f4 mov %rsi,%r12
645: 55 push %rbp
646: 8d 6c 3f 01 lea 0x1(%rdi,%rdi,1),%ebp
64a: 53 push %rbx
[...]
6ff: 5b pop %rbx
700: 5d pop %rbp
701: 41 5c pop %r12
703: c3 retq
704: e8 57 fe ff ff callq 560 <sqrt@plt>
709: c5 f9 28 c8 vmovapd %xmm0,%xmm1
70d: eb b9 jmp 6c8 <_Z2goiPKi+0x88>
70f: 90 nop
In fact there's nothing at all at the CIE range 000007a0..0000086f - the
address is in unwind info table itself (.eh_frame), not in the code. So it
looks like whatever is generating this unwind info is generating wrong address
references.
$ readelf -WS libfoo_hlto.so
There are 29 section headers, starting at offset 0x1100:
Section Headers:
[Nr] Name Type Address Off Size ES Flg
Lk Inf Al
[...]
[14] .eh_frame PROGBITS 0000000000000778 000778 000058 00 A
0 0 8
[15] .eh_frame_hdr PROGBITS 00000000000007d0 0007d0 000014 00 A
0 0 4
[...]
Looks like your tool chain is broken. I don't know why.
More information about the Gcc-bugs
mailing list