[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.
- [Bug gold/17639] New: Malformed .eh_frame generated with LTO, gold and optimization enabled,
peter at lekensteyn dot nl <=
- [Bug gold/17639] Malformed .eh_frame generated with LTO, gold and optimization enabled, peter at lekensteyn dot nl, 2014/11/24
- [Bug gold/17639] Malformed .eh_frame generated with LTO, gold and optimization enabled, address@hidden, 2014/11/25
- [Bug gold/17639] Malformed .eh_frame generated with LTO, gold and optimization enabled, cvs-commit at gcc dot gnu.org, 2014/11/25
- [Bug gold/17639] Malformed .eh_frame generated with LTO, gold and optimization enabled, ccoutant at google dot com, 2014/11/25
- [Bug gold/17639] Malformed .eh_frame generated with LTO, gold and optimization enabled, peter at lekensteyn dot nl, 2014/11/25
- [Bug gold/17639] Malformed .eh_frame generated with LTO, gold and optimization enabled, cvs-commit at gcc dot gnu.org, 2014/11/25