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

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

33 lines
1002 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
[test] lld/test/: change llvm-objdump single-dash long options to double-dash options
2020-03-16 08:47:44 +08:00
# RUN: llvm-objdump -s --dwarf=frames %t | FileCheck %s
[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
[llvm-objdump] Further rearrange llvm-objdump sections for compatability Summary: rL371826 rearranged some output from llvm-objdump for GNU objdump compatability, but there still seem to be some more. I think this rearrangement is a little closer. Overview of the ordering which matches GNU objdump: * Archive headers * File headers * Section headers * Symbol table * Dwarf debugging * Relocations (if `--disassemble` is not used) * Section contents * Disassembly Reviewers: jhenderson, justice_adams, grimar, ychen, espindola Reviewed By: jhenderson Subscribers: aprantl, emaste, arichardson, jrtc27, atanasyan, seiya, llvm-commits, MaskRay Tags: #llvm Differential Revision: https://reviews.llvm.org/D68066 llvm-svn: 373671
2019-10-04 06:01:08 +08:00
# CHECK: Augmentation: "zLR"
# 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
# CHECK: Contents of section .eh_frame_hdr:
[ELF][X86] Allow PT_LOAD to have overlapping p_offset ranges on EM_X86_64 Port the D64906 technique to EM_X86_64. Differential Revision: https://reviews.llvm.org/D67482 llvm-svn: 371958
2019-09-16 15:05:34 +08:00
# CHECK-NEXT: 200190 011b033b 14000000 01000000 54100000
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
# ^-- 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:
[ELF][X86] Allow PT_LOAD to have overlapping p_offset ranges on EM_X86_64 Port the D64906 technique to EM_X86_64. Differential Revision: https://reviews.llvm.org/D67482 llvm-svn: 371958
2019-09-16 15:05:34 +08:00
# CHECK-NEXT: 2011e4 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
.text
.globl __start
__start:
.cfi_startproc
.cfi_lsda 0, _ex
nop
.cfi_endproc
.data
_ex:
.word 0