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.

Reply via email to