maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/COFF/secidx-absolute.s

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

35 lines
907 B
ArmAsm
Raw Normal View History

[lld] Add REQUIRES: x86 where needed to tests If building lld without x86 support, tests that require that support should be treated as unsupported, not errors. Tested using: 1. cmake '-DLLVM_TARGETS_TO_BUILD=AArch64;X86' make check-lld => Expected Passes : 1406 Unsupported Tests : 287 2. cmake '-DLLVM_TARGETS_TO_BUILD=AArch64' make check-lld => Expected Passes : 410 Unsupported Tests : 1283 Patch by Joel Jones Differential Revision: https://reviews.llvm.org/D47748 llvm-svn: 334095
2018-06-06 21:56:51 +08:00
# REQUIRES: x86
[COFF] Fix SECTION and SECREL relocation handling for absolute symbols Summary: For SECTION relocations against absolute symbols, MSVC emits the largest output section index plus one. I've implemented that by threading a global variable through DefinedAbsolute that is filled in by the Writer. A more library-oriented approach would be to thread the Writer through Chunk::writeTo and SectionChunk::applyRel*, but Rui seems to prefer doing it this way. MSVC rejects SECREL relocations against absolute symbols, but only when the relocation is in a real output section. When the relocation is in a CodeView debug info section destined for the PDB, it seems that this relocation error is suppressed, and absolute symbols become zeros in the object file. This is easily implemented by checking the input section from which we're applying relocations. This should fix errors about __safe_se_handler_table and __guard_fids_table when linking the CRT and generating a PDB. Reviewers: ruiu Subscribers: aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D34541 llvm-svn: 306071
2017-06-23 07:33:04 +08:00
# RUN: llvm-mc %s -filetype=obj -triple=x86_64-windows-msvc -o %t.obj
# RUN: lld-link -entry:main -nodefaultlib %t.obj -out:%t.exe
# RUN: llvm-readobj %t.exe -sections -section-data | FileCheck %s
[lld] NFC: fix trivial typos in comments Differential Revision: https://reviews.llvm.org/D72339
2020-04-02 00:21:08 +08:00
# Section relocations against absolute symbols resolve to the last real output
[COFF] Fix SECTION and SECREL relocation handling for absolute symbols Summary: For SECTION relocations against absolute symbols, MSVC emits the largest output section index plus one. I've implemented that by threading a global variable through DefinedAbsolute that is filled in by the Writer. A more library-oriented approach would be to thread the Writer through Chunk::writeTo and SectionChunk::applyRel*, but Rui seems to prefer doing it this way. MSVC rejects SECREL relocations against absolute symbols, but only when the relocation is in a real output section. When the relocation is in a CodeView debug info section destined for the PDB, it seems that this relocation error is suppressed, and absolute symbols become zeros in the object file. This is easily implemented by checking the input section from which we're applying relocations. This should fix errors about __safe_se_handler_table and __guard_fids_table when linking the CRT and generating a PDB. Reviewers: ruiu Subscribers: aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D34541 llvm-svn: 306071
2017-06-23 07:33:04 +08:00
# section index plus one.
.text
.global main
main:
ret
.section .rdata,"dr"
.secidx __guard_fids_table
# CHECK: Sections [
# CHECK: Section {
# CHECK: Number: 1
COFF: Layout sections in the same order as link.exe One place where this seems to matter is to make sure the .rsrc section comes after .text. The Win32 UpdateResource() function can change the contents of .rsrc. It will move the sections that come after, but if .text gets moved, the entry point header will not get updated and the executable breaks. This was found by a test in Chromium. Differential Revision: https://reviews.llvm.org/D45260 llvm-svn: 329221
2018-04-05 03:15:55 +08:00
# CHECK: Name: .text (2E 74 65 78 74 00 00 00)
# CHECK: VirtualSize: 0x1
[COFF] Fix SECTION and SECREL relocation handling for absolute symbols Summary: For SECTION relocations against absolute symbols, MSVC emits the largest output section index plus one. I've implemented that by threading a global variable through DefinedAbsolute that is filled in by the Writer. A more library-oriented approach would be to thread the Writer through Chunk::writeTo and SectionChunk::applyRel*, but Rui seems to prefer doing it this way. MSVC rejects SECREL relocations against absolute symbols, but only when the relocation is in a real output section. When the relocation is in a CodeView debug info section destined for the PDB, it seems that this relocation error is suppressed, and absolute symbols become zeros in the object file. This is easily implemented by checking the input section from which we're applying relocations. This should fix errors about __safe_se_handler_table and __guard_fids_table when linking the CRT and generating a PDB. Reviewers: ruiu Subscribers: aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D34541 llvm-svn: 306071
2017-06-23 07:33:04 +08:00
# CHECK: SectionData (
COFF: Layout sections in the same order as link.exe One place where this seems to matter is to make sure the .rsrc section comes after .text. The Win32 UpdateResource() function can change the contents of .rsrc. It will move the sections that come after, but if .text gets moved, the entry point header will not get updated and the executable breaks. This was found by a test in Chromium. Differential Revision: https://reviews.llvm.org/D45260 llvm-svn: 329221
2018-04-05 03:15:55 +08:00
# CHECK: 0000: C3 |.|
[COFF] Fix SECTION and SECREL relocation handling for absolute symbols Summary: For SECTION relocations against absolute symbols, MSVC emits the largest output section index plus one. I've implemented that by threading a global variable through DefinedAbsolute that is filled in by the Writer. A more library-oriented approach would be to thread the Writer through Chunk::writeTo and SectionChunk::applyRel*, but Rui seems to prefer doing it this way. MSVC rejects SECREL relocations against absolute symbols, but only when the relocation is in a real output section. When the relocation is in a CodeView debug info section destined for the PDB, it seems that this relocation error is suppressed, and absolute symbols become zeros in the object file. This is easily implemented by checking the input section from which we're applying relocations. This should fix errors about __safe_se_handler_table and __guard_fids_table when linking the CRT and generating a PDB. Reviewers: ruiu Subscribers: aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D34541 llvm-svn: 306071
2017-06-23 07:33:04 +08:00
# CHECK: )
# CHECK: }
# CHECK: Section {
# CHECK: Number: 2
COFF: Layout sections in the same order as link.exe One place where this seems to matter is to make sure the .rsrc section comes after .text. The Win32 UpdateResource() function can change the contents of .rsrc. It will move the sections that come after, but if .text gets moved, the entry point header will not get updated and the executable breaks. This was found by a test in Chromium. Differential Revision: https://reviews.llvm.org/D45260 llvm-svn: 329221
2018-04-05 03:15:55 +08:00
# CHECK: Name: .rdata (2E 72 64 61 74 61 00 00)
[COFF] Fix SECTION and SECREL relocation handling for absolute symbols Summary: For SECTION relocations against absolute symbols, MSVC emits the largest output section index plus one. I've implemented that by threading a global variable through DefinedAbsolute that is filled in by the Writer. A more library-oriented approach would be to thread the Writer through Chunk::writeTo and SectionChunk::applyRel*, but Rui seems to prefer doing it this way. MSVC rejects SECREL relocations against absolute symbols, but only when the relocation is in a real output section. When the relocation is in a CodeView debug info section destined for the PDB, it seems that this relocation error is suppressed, and absolute symbols become zeros in the object file. This is easily implemented by checking the input section from which we're applying relocations. This should fix errors about __safe_se_handler_table and __guard_fids_table when linking the CRT and generating a PDB. Reviewers: ruiu Subscribers: aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D34541 llvm-svn: 306071
2017-06-23 07:33:04 +08:00
# CHECK: SectionData (
COFF: Layout sections in the same order as link.exe One place where this seems to matter is to make sure the .rsrc section comes after .text. The Win32 UpdateResource() function can change the contents of .rsrc. It will move the sections that come after, but if .text gets moved, the entry point header will not get updated and the executable breaks. This was found by a test in Chromium. Differential Revision: https://reviews.llvm.org/D45260 llvm-svn: 329221
2018-04-05 03:15:55 +08:00
# CHECK: 0000: 0300 |..|
[COFF] Fix SECTION and SECREL relocation handling for absolute symbols Summary: For SECTION relocations against absolute symbols, MSVC emits the largest output section index plus one. I've implemented that by threading a global variable through DefinedAbsolute that is filled in by the Writer. A more library-oriented approach would be to thread the Writer through Chunk::writeTo and SectionChunk::applyRel*, but Rui seems to prefer doing it this way. MSVC rejects SECREL relocations against absolute symbols, but only when the relocation is in a real output section. When the relocation is in a CodeView debug info section destined for the PDB, it seems that this relocation error is suppressed, and absolute symbols become zeros in the object file. This is easily implemented by checking the input section from which we're applying relocations. This should fix errors about __safe_se_handler_table and __guard_fids_table when linking the CRT and generating a PDB. Reviewers: ruiu Subscribers: aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D34541 llvm-svn: 306071
2017-06-23 07:33:04 +08:00
# CHECK: )
# CHECK: }
# CHECK-NOT: Section
# CHECK: ]