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

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

101 lines
5.1 KiB
ArmAsm
Raw Normal View History

Fix the fde encoding used by mips to match gas. This finally fixes the encoding. The patch also * Removes eh-frame.ll. It was an unnecessary .ll to .o test that was checking the wrong value. * Merge fde-reloc.s and eh-frame.s into a single test, since the only difference was the run lines. * Don't blindly test the content of the entire .eh_frame section. It makes it hard to anyone actually fixing a bug and hitting a difference in a binary blob. Instead, use a CHECK for each field and document what is being checked. llvm-svn: 178615
2013-04-03 11:13:19 +08:00
// Test the bits of .eh_frame on mips that are already implemented correctly.
Mips direct object exception handling regression Revision 177141 caused a regression in all but mips64 little endian. That is because none of the other Mips targets had test cases checking the contents of the .eh_frame section. This patch fixes both the llvm code and adds an assembler test case to include the current 4 flavors. The test cases unfortunately rely on llvm-objdump. A preferable method would be to use a pretty printer output such as what readelf -wf <elf_file> would give. I also changed the name of the test case to correct a typo. llvm-svn: 178506
2013-04-02 05:55:15 +08:00
[mips] Use llvm-mc -triple option instead of combination of arch,target-abi,mcpu. NFC llvm-svn: 348914
2018-12-12 15:03:04 +08:00
// RUN: llvm-mc -filetype=obj %s -o %t.o -triple mips-unknown-linux-gnu
[MIPS][ELF] Use PC-relative relocations in .eh_frame when possible When compiling position-independent executables, we now use DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a 64-bit PC-relative ELF relocation so we cannot use sdata8 for the large code model case. When using the large code model, we fall back to the previous behaviour of generating absolute relocations. With this change clang-generated .o files can be linked by LLD without having to pass -Wl,-z,notext (which creates text relocations). This is simpler than the approach used by ld.bfd, which rewrites the .eh_frame section to convert absolute relocations into relative references. I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations for MIPS ouput at some point. However, I also checked that recent ld.bfd can process the clang-generated .o files so this no longer seems true. Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72228
2020-01-12 18:55:15 +08:00
// RUN: llvm-readobj -r %t.o | FileCheck --check-prefixes=RELOCS,ABS32 %s
// RUN: llvm-dwarfdump -eh-frame %t.o | FileCheck --check-prefixes=DWARF32,DWARF32_ABS %s
Mips direct object exception handling regression Revision 177141 caused a regression in all but mips64 little endian. That is because none of the other Mips targets had test cases checking the contents of the .eh_frame section. This patch fixes both the llvm code and adds an assembler test case to include the current 4 flavors. The test cases unfortunately rely on llvm-objdump. A preferable method would be to use a pretty printer output such as what readelf -wf <elf_file> would give. I also changed the name of the test case to correct a typo. llvm-svn: 178506
2013-04-02 05:55:15 +08:00
[mips] Use llvm-mc -triple option instead of combination of arch,target-abi,mcpu. NFC llvm-svn: 348914
2018-12-12 15:03:04 +08:00
// RUN: llvm-mc -filetype=obj %s -o %t.o -triple mipsel-unknown-linux-gnu
[MIPS][ELF] Use PC-relative relocations in .eh_frame when possible When compiling position-independent executables, we now use DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a 64-bit PC-relative ELF relocation so we cannot use sdata8 for the large code model case. When using the large code model, we fall back to the previous behaviour of generating absolute relocations. With this change clang-generated .o files can be linked by LLD without having to pass -Wl,-z,notext (which creates text relocations). This is simpler than the approach used by ld.bfd, which rewrites the .eh_frame section to convert absolute relocations into relative references. I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations for MIPS ouput at some point. However, I also checked that recent ld.bfd can process the clang-generated .o files so this no longer seems true. Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72228
2020-01-12 18:55:15 +08:00
// RUN: llvm-readobj -r %t.o | FileCheck --check-prefixes=RELOCS,ABS32 %s
// RUN: llvm-dwarfdump -eh-frame %t.o | FileCheck --check-prefixes=DWARF32,DWARF32_ABS %s
Mips direct object exception handling regression Revision 177141 caused a regression in all but mips64 little endian. That is because none of the other Mips targets had test cases checking the contents of the .eh_frame section. This patch fixes both the llvm code and adds an assembler test case to include the current 4 flavors. The test cases unfortunately rely on llvm-objdump. A preferable method would be to use a pretty printer output such as what readelf -wf <elf_file> would give. I also changed the name of the test case to correct a typo. llvm-svn: 178506
2013-04-02 05:55:15 +08:00
[mips] Use llvm-mc -triple option instead of combination of arch,target-abi,mcpu. NFC llvm-svn: 348914
2018-12-12 15:03:04 +08:00
// RUN: llvm-mc -filetype=obj %s -o %t.o -triple mips64-unknown-linux-gnu
[MIPS][ELF] Use PC-relative relocations in .eh_frame when possible When compiling position-independent executables, we now use DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a 64-bit PC-relative ELF relocation so we cannot use sdata8 for the large code model case. When using the large code model, we fall back to the previous behaviour of generating absolute relocations. With this change clang-generated .o files can be linked by LLD without having to pass -Wl,-z,notext (which creates text relocations). This is simpler than the approach used by ld.bfd, which rewrites the .eh_frame section to convert absolute relocations into relative references. I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations for MIPS ouput at some point. However, I also checked that recent ld.bfd can process the clang-generated .o files so this no longer seems true. Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72228
2020-01-12 18:55:15 +08:00
// RUN: llvm-readobj -r %t.o | FileCheck --check-prefixes=RELOCS,ABS64 %s
// RUN: llvm-dwarfdump -eh-frame %t.o | FileCheck --check-prefixes=DWARF64,DWARF64_ABS %s
Mips direct object exception handling regression Revision 177141 caused a regression in all but mips64 little endian. That is because none of the other Mips targets had test cases checking the contents of the .eh_frame section. This patch fixes both the llvm code and adds an assembler test case to include the current 4 flavors. The test cases unfortunately rely on llvm-objdump. A preferable method would be to use a pretty printer output such as what readelf -wf <elf_file> would give. I also changed the name of the test case to correct a typo. llvm-svn: 178506
2013-04-02 05:55:15 +08:00
[mips] Use llvm-mc -triple option instead of combination of arch,target-abi,mcpu. NFC llvm-svn: 348914
2018-12-12 15:03:04 +08:00
// RUN: llvm-mc -filetype=obj %s -o %t.o -triple mips64el-unknown-linux-gnu
[MIPS][ELF] Use PC-relative relocations in .eh_frame when possible When compiling position-independent executables, we now use DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a 64-bit PC-relative ELF relocation so we cannot use sdata8 for the large code model case. When using the large code model, we fall back to the previous behaviour of generating absolute relocations. With this change clang-generated .o files can be linked by LLD without having to pass -Wl,-z,notext (which creates text relocations). This is simpler than the approach used by ld.bfd, which rewrites the .eh_frame section to convert absolute relocations into relative references. I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations for MIPS ouput at some point. However, I also checked that recent ld.bfd can process the clang-generated .o files so this no longer seems true. Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72228
2020-01-12 18:55:15 +08:00
// RUN: llvm-readobj -r %t.o | FileCheck --check-prefixes=RELOCS,ABS64 %s
// RUN: llvm-dwarfdump -eh-frame %t.o | FileCheck --check-prefixes=DWARF64,DWARF64_ABS %s
/// Check that position-indenpendent code use PC-relative relocations:
// RUN: llvm-mc -filetype=obj %s -o %t.o -triple mips-unknown-linux-gnu --position-independent
// RUN: llvm-readobj -r %t.o | FileCheck --check-prefixes=RELOCS,PIC32 %s
// RUN: llvm-dwarfdump -eh-frame %t.o | FileCheck --check-prefixes=DWARF32,DWARF32_PIC %s
// RUN: llvm-mc -filetype=obj %s -o %t.o -triple mipsel-unknown-linux-gnu --position-independent
// RUN: llvm-readobj -r %t.o | FileCheck --check-prefixes=RELOCS,PIC32 %s
// RUN: llvm-dwarfdump -eh-frame %t.o | FileCheck --check-prefixes=DWARF32,DWARF32_PIC %s
// RUN: llvm-mc -filetype=obj %s -o %t.o -triple mips64-unknown-linux-gnu --position-independent
// RUN: llvm-readobj -r %t.o | FileCheck --check-prefixes=RELOCS,PIC64 %s
// RUN: llvm-dwarfdump -eh-frame %t.o | FileCheck --check-prefixes=DWARF64,DWARF64_PIC %s
// RUN: llvm-mc -filetype=obj %s -o %t.o -triple mips64el-unknown-linux-gnu --position-independent
// RUN: llvm-readobj -r %t.o | FileCheck --check-prefixes=RELOCS,PIC64 %s
// RUN: llvm-dwarfdump -eh-frame %t.o | FileCheck --check-prefixes=DWARF64,DWARF64_PIC %s
/// However using the large code model forces R_MIPS_64 since there is no R_MIPS_PC64 relocation:
// RUN: llvm-mc -filetype=obj %s -o %t.o -triple mips64-unknown-linux-gnu --position-independent --large-code-model
// RUN: llvm-readobj -r %t.o | FileCheck --check-prefixes=RELOCS,ABS64 %s
// RUN: llvm-dwarfdump -eh-frame %t.o | FileCheck --check-prefixes=DWARF64,DWARF64_ABS %s
// RUN: llvm-mc -filetype=obj %s -o %t.o -triple mips64el-unknown-linux-gnu --position-independent --large-code-model
// RUN: llvm-readobj -r %t.o | FileCheck --check-prefixes=RELOCS,ABS64 %s
// RUN: llvm-dwarfdump -eh-frame %t.o | FileCheck --check-prefixes=DWARF64,DWARF64_ABS %s
Mips direct object exception handling regression Revision 177141 caused a regression in all but mips64 little endian. That is because none of the other Mips targets had test cases checking the contents of the .eh_frame section. This patch fixes both the llvm code and adds an assembler test case to include the current 4 flavors. The test cases unfortunately rely on llvm-objdump. A preferable method would be to use a pretty printer output such as what readelf -wf <elf_file> would give. I also changed the name of the test case to correct a typo. llvm-svn: 178506
2013-04-02 05:55:15 +08:00
Fix the fde encoding used by mips to match gas. This finally fixes the encoding. The patch also * Removes eh-frame.ll. It was an unnecessary .ll to .o test that was checking the wrong value. * Merge fde-reloc.s and eh-frame.s into a single test, since the only difference was the run lines. * Don't blindly test the content of the entire .eh_frame section. It makes it hard to anyone actually fixing a bug and hitting a difference in a binary blob. Instead, use a CHECK for each field and document what is being checked. llvm-svn: 178615
2013-04-03 11:13:19 +08:00
func:
.cfi_startproc
.cfi_endproc
Mips direct object exception handling regression Revision 177141 caused a regression in all but mips64 little endian. That is because none of the other Mips targets had test cases checking the contents of the .eh_frame section. This patch fixes both the llvm code and adds an assembler test case to include the current 4 flavors. The test cases unfortunately rely on llvm-objdump. A preferable method would be to use a pretty printer output such as what readelf -wf <elf_file> would give. I also changed the name of the test case to correct a typo. llvm-svn: 178506
2013-04-02 05:55:15 +08:00
[MIPS][ELF] Use PC-relative relocations in .eh_frame when possible When compiling position-independent executables, we now use DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a 64-bit PC-relative ELF relocation so we cannot use sdata8 for the large code model case. When using the large code model, we fall back to the previous behaviour of generating absolute relocations. With this change clang-generated .o files can be linked by LLD without having to pass -Wl,-z,notext (which creates text relocations). This is simpler than the approach used by ld.bfd, which rewrites the .eh_frame section to convert absolute relocations into relative references. I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations for MIPS ouput at some point. However, I also checked that recent ld.bfd can process the clang-generated .o files so this no longer seems true. Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72228
2020-01-12 18:55:15 +08:00
// RELOCS: Relocations [
// RELOCS: Section ({{.+}}) .rel{{a?}}.eh_frame {
// ABS32-NEXT: R_MIPS_32
// ABS64-NEXT: R_MIPS_64/R_MIPS_NONE/R_MIPS_NONE
// PIC32-NEXT: R_MIPS_PC32
// PIC64-NEXT: R_MIPS_PC32/R_MIPS_NONE/R_MIPS_NONE
// RELOCS-NEXT: }
[mips] Use llvm-dwarfdump to simplify the test. NFC llvm-svn: 314222
2017-09-27 01:02:35 +08:00
[DebugInfo] Fix dumping CIE ID in .eh_frame sections. We do not keep the actual value of the CIE ID field, because it is predefined, and use a constant when dumping a CIE record. The issue was that the predefined value is different for .debug_frame and .eh_frame sections, but we always printed the one which corresponds to .debug_frame. The patch fixes that by choosing an appropriate constant to print. See the following for more information about .eh_frame sections: https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html Differential Revision: https://reviews.llvm.org/D73627
2020-01-29 22:28:46 +08:00
// DWARF32: 00000000 00000010 00000000 CIE
[DebugInfo] Report the format of call frame information entries [6/10] Differential Revision: https://reviews.llvm.org/D80523
2020-06-02 17:00:44 +08:00
// DWARF32-NEXT: Format: DWARF32
[MIPS][ELF] Use PC-relative relocations in .eh_frame when possible When compiling position-independent executables, we now use DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a 64-bit PC-relative ELF relocation so we cannot use sdata8 for the large code model case. When using the large code model, we fall back to the previous behaviour of generating absolute relocations. With this change clang-generated .o files can be linked by LLD without having to pass -Wl,-z,notext (which creates text relocations). This is simpler than the approach used by ld.bfd, which rewrites the .eh_frame section to convert absolute relocations into relative references. I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations for MIPS ouput at some point. However, I also checked that recent ld.bfd can process the clang-generated .o files so this no longer seems true. Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72228
2020-01-12 18:55:15 +08:00
// DWARF32-NEXT: Version: 1
// DWARF32-NEXT: Augmentation: "zR"
// DWARF32-NEXT: Code alignment factor: 1
// DWARF32-NEXT: Data alignment factor: -4
// DWARF32-NEXT: Return address column: 31
// DWARF32_ABS-NEXT: Augmentation data: 0B
// ^^ fde pointer encoding: DW_EH_PE_sdata4
// DWARF32_PIC-NEXT: Augmentation data: 1B
// ^^ fde pointer encoding: DW_EH_PE_pcrel | DW_EH_PE_sdata4
// DWARF32-EMPTY:
// DWARF32-NEXT: DW_CFA_def_cfa_register: reg29
[mips] Use llvm-dwarfdump to simplify the test. NFC llvm-svn: 314222
2017-09-27 01:02:35 +08:00
//
[DebugInfo] Fix printing CIE offsets in EH FDEs. While the value of the CIE pointer field in a DWARF FDE record is an offset to the corresponding CIE record from the beginning of the section, for EH FDE records it is relative to the current offset. Previously, we did not make that distinction when dumped both kinds of FDE records and just printed the same value for the CIE pointer field and the CIE offset; that was acceptable for DWARF FDEs but was wrong for EH FDEs. This patch fixes the issue by explicitly printing the offset of the linked CIE object. Differential Revision: https://reviews.llvm.org/D74613
2020-02-13 19:20:14 +08:00
// DWARF32: 00000014 00000010 00000018 FDE cie=00000000 pc=00000000...00000000
[DebugInfo] Report the format of call frame information entries [6/10] Differential Revision: https://reviews.llvm.org/D80523
2020-06-02 17:00:44 +08:00
// DWARF32-NEXT: Format: DWARF32
[MIPS][ELF] Use PC-relative relocations in .eh_frame when possible When compiling position-independent executables, we now use DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a 64-bit PC-relative ELF relocation so we cannot use sdata8 for the large code model case. When using the large code model, we fall back to the previous behaviour of generating absolute relocations. With this change clang-generated .o files can be linked by LLD without having to pass -Wl,-z,notext (which creates text relocations). This is simpler than the approach used by ld.bfd, which rewrites the .eh_frame section to convert absolute relocations into relative references. I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations for MIPS ouput at some point. However, I also checked that recent ld.bfd can process the clang-generated .o files so this no longer seems true. Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72228
2020-01-12 18:55:15 +08:00
// DWARF32-NEXT: DW_CFA_nop:
// DWARF32-NEXT: DW_CFA_nop:
// DWARF32-NEXT: DW_CFA_nop:
[mips] Use llvm-dwarfdump to simplify the test. NFC llvm-svn: 314222
2017-09-27 01:02:35 +08:00
[DebugInfo] Fix dumping CIE ID in .eh_frame sections. We do not keep the actual value of the CIE ID field, because it is predefined, and use a constant when dumping a CIE record. The issue was that the predefined value is different for .debug_frame and .eh_frame sections, but we always printed the one which corresponds to .debug_frame. The patch fixes that by choosing an appropriate constant to print. See the following for more information about .eh_frame sections: https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html Differential Revision: https://reviews.llvm.org/D73627
2020-01-29 22:28:46 +08:00
// DWARF64: 00000000 00000010 00000000 CIE
[DebugInfo] Report the format of call frame information entries [6/10] Differential Revision: https://reviews.llvm.org/D80523
2020-06-02 17:00:44 +08:00
// DWARF64-NEXT: Format: DWARF32
[MIPS][ELF] Use PC-relative relocations in .eh_frame when possible When compiling position-independent executables, we now use DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a 64-bit PC-relative ELF relocation so we cannot use sdata8 for the large code model case. When using the large code model, we fall back to the previous behaviour of generating absolute relocations. With this change clang-generated .o files can be linked by LLD without having to pass -Wl,-z,notext (which creates text relocations). This is simpler than the approach used by ld.bfd, which rewrites the .eh_frame section to convert absolute relocations into relative references. I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations for MIPS ouput at some point. However, I also checked that recent ld.bfd can process the clang-generated .o files so this no longer seems true. Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72228
2020-01-12 18:55:15 +08:00
// DWARF64-NEXT: Version: 1
// DWARF64-NEXT: Augmentation: "zR"
// DWARF64-NEXT: Code alignment factor: 1
// DWARF64-NEXT: Data alignment factor: -8
// ^^ GAS uses -4. Should be ok as long as
// all offsets we need are a multiple of 8.
// DWARF64-NEXT: Return address column: 31
// DWARF64_ABS-NEXT: Augmentation data: 0C
// ^^ fde pointer encoding: DW_EH_PE_sdata8
// DWARF64_PIC: Augmentation data: 1B
// ^^ fde pointer encoding: DW_EH_PE_pcrel | DW_EH_PE_sdata4
// DWARF64-EMPTY:
// DWARF64-NEXT: DW_CFA_def_cfa_register: reg29
// DWARF64_PIC-NEXT: DW_CFA_nop:
[mips] Use llvm-dwarfdump to simplify the test. NFC llvm-svn: 314222
2017-09-27 01:02:35 +08:00
//
[DebugInfo] Fix printing CIE offsets in EH FDEs. While the value of the CIE pointer field in a DWARF FDE record is an offset to the corresponding CIE record from the beginning of the section, for EH FDE records it is relative to the current offset. Previously, we did not make that distinction when dumped both kinds of FDE records and just printed the same value for the CIE pointer field and the CIE offset; that was acceptable for DWARF FDEs but was wrong for EH FDEs. This patch fixes the issue by explicitly printing the offset of the linked CIE object. Differential Revision: https://reviews.llvm.org/D74613
2020-02-13 19:20:14 +08:00
// DWARF64_ABS: 00000014 00000018 00000018 FDE cie=00000000 pc=00000000...00000000
// DWARF64_PIC: 00000014 00000010 00000018 FDE cie=00000000 pc=00000000...00000000
[DebugInfo] Report the format of call frame information entries [6/10] Differential Revision: https://reviews.llvm.org/D80523
2020-06-02 17:00:44 +08:00
// DWARF64-NEXT: Format: DWARF32
[MIPS][ELF] Use PC-relative relocations in .eh_frame when possible When compiling position-independent executables, we now use DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a 64-bit PC-relative ELF relocation so we cannot use sdata8 for the large code model case. When using the large code model, we fall back to the previous behaviour of generating absolute relocations. With this change clang-generated .o files can be linked by LLD without having to pass -Wl,-z,notext (which creates text relocations). This is simpler than the approach used by ld.bfd, which rewrites the .eh_frame section to convert absolute relocations into relative references. I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations for MIPS ouput at some point. However, I also checked that recent ld.bfd can process the clang-generated .o files so this no longer seems true. Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72228
2020-01-12 18:55:15 +08:00
// DWARF64-NEXT: DW_CFA_nop:
// DWARF64-NEXT: DW_CFA_nop:
// DWARF64-NEXT: DW_CFA_nop: