maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/DebugInfo/X86/eh-frame-cie-id.s

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

15 lines
557 B
ArmAsm
Raw Normal View History

[DebugInfo] - DWARFDebugFrame: do not call abort() on errors. Imagine we have a broken .eh_frame. Below is a possible sample output of llvm-readelf: ``` ... entry 2 { initial_location: 0x10f5 address: 0x2080 } } } .eh_frame section at offset 0x2028 address 0x2028: LLVM ERROR: Parsing entry instructions at 0 failed PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /home/umb/LLVM/LLVM/llvm-project/build/bin/llvm-readelf -a 1 #0 0x000055f4a2ff5a1a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/umb/LLVM/LLVM/llvm-project/build/bin/llvm-readelf+0x2b9a1a) ... #15 0x00007fdae5dc209b __libc_start_main /build/glibc-B9XfQf/glibc-2.28/csu/../csu/libc-start.c:342:3 #16 0x000055f4a2db746a _start (/home/umb/LLVM/LLVM/llvm-project/build/bin/llvm-readelf+0x7b46a) Aborted ``` I.e. it calls abort(), suggests to submit a bug report and exits with the code 134. This patch changes the logic to propagate errors to callers. This fixes the behavior for llvm-dwarfdump, llvm-readobj and other possible tools. Differential revision: https://reviews.llvm.org/D79165
2020-04-30 16:36:54 +08:00
# RUN: llvm-mc -triple x86_64-unknown-linux %s -filetype=obj -o %t
# RUN: not llvm-dwarfdump -debug-frame %t 2>&1 | FileCheck %s
[DebugInfo] Refine the condition to detect CIEs. The condition was not accurate enough and could interpret some FDEs in .eh_frame or 64-bit DWARF .debug_frame sections as CIEs. Even though such FDEs are unlikely in a normal situation, the wrong interpretation could hide an issue in a buggy generator. Differential Revision: https://reviews.llvm.org/D73886
2020-02-03 19:00:56 +08:00
[DebugInfo] - DWARFDebugFrame: do not call abort() on errors. Imagine we have a broken .eh_frame. Below is a possible sample output of llvm-readelf: ``` ... entry 2 { initial_location: 0x10f5 address: 0x2080 } } } .eh_frame section at offset 0x2028 address 0x2028: LLVM ERROR: Parsing entry instructions at 0 failed PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /home/umb/LLVM/LLVM/llvm-project/build/bin/llvm-readelf -a 1 #0 0x000055f4a2ff5a1a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/umb/LLVM/LLVM/llvm-project/build/bin/llvm-readelf+0x2b9a1a) ... #15 0x00007fdae5dc209b __libc_start_main /build/glibc-B9XfQf/glibc-2.28/csu/../csu/libc-start.c:342:3 #16 0x000055f4a2db746a _start (/home/umb/LLVM/LLVM/llvm-project/build/bin/llvm-readelf+0x7b46a) Aborted ``` I.e. it calls abort(), suggests to submit a bug report and exits with the code 134. This patch changes the logic to propagate errors to callers. This fixes the behavior for llvm-dwarfdump, llvm-readobj and other possible tools. Differential revision: https://reviews.llvm.org/D79165
2020-04-30 16:36:54 +08:00
# CHECK: parsing FDE data at 0x0 failed due to missing CIE
[DebugInfo] Refine the condition to detect CIEs. The condition was not accurate enough and could interpret some FDEs in .eh_frame or 64-bit DWARF .debug_frame sections as CIEs. Even though such FDEs are unlikely in a normal situation, the wrong interpretation could hide an issue in a buggy generator. Differential Revision: https://reviews.llvm.org/D73886
2020-02-03 19:00:56 +08:00
.section .eh_frame,"a",@unwind
## This FDE was formerly wrongly interpreted as a CIE because its CIE pointer
## is similar to CIE id of a .debug_frame FDE.
.long .Lend - .LCIEptr # Length
.LCIEptr:
.long 0xffffffff # CIE pointer
.quad 0x1111abcd # Initial location
.quad 0x00010000 # Address range
.Lend: