bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gold/17639] New: Malformed .eh_frame generated with LTO, gold and o


From: peter at lekensteyn dot nl
Subject: [Bug gold/17639] New: Malformed .eh_frame generated with LTO, gold and optimization enabled
Date: Mon, 24 Nov 2014 13:52:59 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=17639

            Bug ID: 17639
           Summary: Malformed .eh_frame generated with LTO, gold and
                    optimization enabled
           Product: binutils
           Version: 2.24
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gold
          Assignee: ccoutant at google dot com
          Reporter: peter at lekensteyn dot nl
                CC: ian at airs dot com

(originally reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64046)

While trying to track down a weird crash in libunwind, I found that the library
I was debugging (libgudev-1.0.so.0.2.0) has a weird .eh_frame. I could minimize
the problem to:

    echo 'int main(void) { return 0; }' > hello.c
    gcc -shared -Wl,-fuse-ld=gold -fPIC -flto -ffat-lto-objects -O2 hello.c
-Wl,--gc-sections
    readelf --hex-dump=.eh_frame a.out | head -n5

Omitting any of the gcc options would result in a .eh_frame section that does
not look odd. Output of readelf follows (note the leading 8 zeroes, and the
warning about the invalid FDE length).

Hex dump of section '.eh_frame':
  0x000006b0 00000000 00000000 14000000 00000000 ................
  0x000006c0 017a5200 01781001 1b0c0708 90010000 .zR..x..........
  0x000006d0 c0feffff 1c000000 00000000 02000000 ................
  0x000006e0 00000000 00000000 24000000 34000000 ........$...4...
  0x000006f0 70feffff 30000000 000e1046 0e184a0f p...0......F..J.
  0x00000700 0b770880 003f1a3b 2a332422 00000000 .w...?.;*3$"....

Contents of the .eh_frame section:

00000000 ZERO terminator


00000004 ZERO terminator


00000008 0000000000000014 00000000 CIE
  Version:               1
  Augmentation:          "zR"
  Code alignment factor: 1
  Data alignment factor: -8
  Return address column: 16
  Augmentation data:     1b

  DW_CFA_def_cfa: r7 (rsp) ofs 8
  DW_CFA_offset: r16 (rip) at cfa-8
  DW_CFA_nop
  DW_CFA_nop
readelf: Warning: Invalid length 0xfffffec0 in FDE at 0x000020

00000020 00000000fffffec0 0000001c FDE cie=00000008
pc=00000000000006d8..00000000000006da
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_??? (User defined call frame op: 0x24)

This .eh_frame encoding looks strange to me as it does not conform to LSB
4.1[1] nor the AMD64 ABI document. It also trips up Wireshark's ELF dissector
(and apparently also readelf).

Linux x86_64
GCC versions 4.8.2-1ubuntu6 (Ubuntu 14.04) and 4.9.2-1 (Arch Linux).
binutils 2.24-8 (Arch Linux)

 [1]:
https://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html
 [2]: http://www.x86-64.org/documentation/abi.pdf

-- 
You are receiving this mail because:
You are on the CC list for the bug.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]