maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/ELF/eh-frame-hdr-abs-fde.s

33 lines
1001 B
ArmAsm
Raw Normal View History

Convert the eh-frame-hdr-abs-fde.s test to use x86 as a target architecture The test checks common functionality. Let's use `x86` (generic LLD target) as a target architecture. llvm-svn: 354336
2019-02-19 23:17:43 +08:00
# REQUIRES: x86
[ELF] Fix reading of PC values of FDEs The patch fixes two related problems: - If CIE augmentation string has 'L' token the CIE contains a byte defines LSDA encoding. We should skip this byte in `getFdeEncoding` routine. Before this fix we do not skip it and if the next token is 'R' treat this byte as FDE encoding. - FDE encoding format has separate flags e.g. DW_EH_PE_pcrel for definition of relative pointers. We should add .eh_frame address to the PC value iif the DW_EH_PE_pcrel is specified. http://www.airs.com/blog/archives/460 There is one more not fixed problem in this code. If PC value is encoded using signed relative format e.g. DW_EH_PE_sdata4 | DW_EH_PE_pcrel we should sign extend result of read32 to perform calculation correctly. I am going to fix that in a separate patch. Differential Revision: http://reviews.llvm.org/D17733 llvm-svn: 262461
2016-03-02 13:38:42 +08:00
# Check reading PC values of FDEs and writing lookup table in the .eh_frame_hdr
# if CIE augmentation string has 'L' token and PC values are encoded using
# absolute (not relative) format.
Convert the eh-frame-hdr-abs-fde.s test to use x86 as a target architecture The test checks common functionality. Let's use `x86` (generic LLD target) as a target architecture. llvm-svn: 354336
2019-02-19 23:17:43 +08:00
# RUN: llvm-mc -filetype=obj -triple x86_64-pc-linux %s -o %t.o
[ELF] Fix reading of PC values of FDEs The patch fixes two related problems: - If CIE augmentation string has 'L' token the CIE contains a byte defines LSDA encoding. We should skip this byte in `getFdeEncoding` routine. Before this fix we do not skip it and if the next token is 'R' treat this byte as FDE encoding. - FDE encoding format has separate flags e.g. DW_EH_PE_pcrel for definition of relative pointers. We should add .eh_frame address to the PC value iif the DW_EH_PE_pcrel is specified. http://www.airs.com/blog/archives/460 There is one more not fixed problem in this code. If PC value is encoded using signed relative format e.g. DW_EH_PE_sdata4 | DW_EH_PE_pcrel we should sign extend result of read32 to perform calculation correctly. I am going to fix that in a separate patch. Differential Revision: http://reviews.llvm.org/D17733 llvm-svn: 262461
2016-03-02 13:38:42 +08:00
# RUN: ld.lld --eh-frame-hdr %t.o -o %t
# RUN: llvm-objdump -s -dwarf=frames %t | FileCheck %s
# CHECK: Contents of section .eh_frame_hdr:
Convert the eh-frame-hdr-abs-fde.s test to use x86 as a target architecture The test checks common functionality. Let's use `x86` (generic LLD target) as a target architecture. llvm-svn: 354336
2019-02-19 23:17:43 +08:00
# CHECK-NEXT: 200190 011b033b 14000000 01000000 700e0000
# ^-- 0x201000 - 0x200190
# .text - .eh_frame_hdr
# CHECK-NEXT: 2001a0 30000000
[ELF] - Add support of proccessing of the rest allocatable synthetic sections from linkerscript. This change continues what was started by D27040 Now all allocatable synthetics should be available from script side. Differential revision: https://reviews.llvm.org/D27131 llvm-svn: 288150
2016-11-30 00:05:27 +08:00
# CHECK: Contents of section .text:
Convert the eh-frame-hdr-abs-fde.s test to use x86 as a target architecture The test checks common functionality. Let's use `x86` (generic LLD target) as a target architecture. llvm-svn: 354336
2019-02-19 23:17:43 +08:00
# CHECK-NEXT: 201000 90
[ELF] Fix reading of PC values of FDEs The patch fixes two related problems: - If CIE augmentation string has 'L' token the CIE contains a byte defines LSDA encoding. We should skip this byte in `getFdeEncoding` routine. Before this fix we do not skip it and if the next token is 'R' treat this byte as FDE encoding. - FDE encoding format has separate flags e.g. DW_EH_PE_pcrel for definition of relative pointers. We should add .eh_frame address to the PC value iif the DW_EH_PE_pcrel is specified. http://www.airs.com/blog/archives/460 There is one more not fixed problem in this code. If PC value is encoded using signed relative format e.g. DW_EH_PE_sdata4 | DW_EH_PE_pcrel we should sign extend result of read32 to perform calculation correctly. I am going to fix that in a separate patch. Differential Revision: http://reviews.llvm.org/D17733 llvm-svn: 262461
2016-03-02 13:38:42 +08:00
# CHECK: Augmentation: "zLR"
Convert the eh-frame-hdr-abs-fde.s test to use x86 as a target architecture The test checks common functionality. Let's use `x86` (generic LLD target) as a target architecture. llvm-svn: 354336
2019-02-19 23:17:43 +08:00
# CHECK: Augmentation data: 00 1B
# ^-- DW_EH_PE_pcrel | DW_EH_PE_udata4 | DW_EH_PE_signed
[ELF] Fix reading of PC values of FDEs The patch fixes two related problems: - If CIE augmentation string has 'L' token the CIE contains a byte defines LSDA encoding. We should skip this byte in `getFdeEncoding` routine. Before this fix we do not skip it and if the next token is 'R' treat this byte as FDE encoding. - FDE encoding format has separate flags e.g. DW_EH_PE_pcrel for definition of relative pointers. We should add .eh_frame address to the PC value iif the DW_EH_PE_pcrel is specified. http://www.airs.com/blog/archives/460 There is one more not fixed problem in this code. If PC value is encoded using signed relative format e.g. DW_EH_PE_sdata4 | DW_EH_PE_pcrel we should sign extend result of read32 to perform calculation correctly. I am going to fix that in a separate patch. Differential Revision: http://reviews.llvm.org/D17733 llvm-svn: 262461
2016-03-02 13:38:42 +08:00
.text
.globl __start
__start:
.cfi_startproc
.cfi_lsda 0, _ex
nop
.cfi_endproc
.data
_ex:
.word 0