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/pdb-secrel-absolute.yaml

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

86 lines
2.9 KiB
YAML
Raw Normal View History

[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: yaml2obj %s -o %t.obj
# RUN: lld-link -debug -entry:main -out:%t.exe -pdb:%t.pdb %t.obj
[LLD/PDB] Write actual records to the globals stream. Previously we were writing an empty globals stream. Windows tools interpret this as "private symbols are not present in this PDB", even when they are, so we need to fix this. Regardless, without it we don't have information about global variables, so we need to fix it anyway. This patch does that. With this patch, the "lm" command in WinDbg correctly reports that we have private symbols available, but the "dv" command still refuses to display local variables. Differential Revision: https://reviews.llvm.org/D36535 llvm-svn: 310743
2017-08-12 03:00:03 +08:00
# RUN: llvm-pdbutil dump -globals %t.pdb | FileCheck %s
[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
# There is an S_GDATA32 symbol record with .secrel32 and .secidx relocations in
# it in this debug info. This is similar to the relocations in the loadcfg.obj
# file in the MSVC CRT. We need to make sure that our relocation logic matches
# MSVC's for these absolute, linker-provided symbols.
[LLD/PDB] Write actual records to the globals stream. Previously we were writing an empty globals stream. Windows tools interpret this as "private symbols are not present in this PDB", even when they are, so we need to fix this. Regardless, without it we don't have information about global variables, so we need to fix it anyway. This patch does that. With this patch, the "lm" command in WinDbg correctly reports that we have private symbols available, but the "dv" command still refuses to display local variables. Differential Revision: https://reviews.llvm.org/D36535 llvm-svn: 310743
2017-08-12 03:00:03 +08:00
# CHECK: Global Symbols
# CHECK-NEXT: ============================================================
# CHECK-NEXT: Records
# CHECK-NEXT: 20 | S_GDATA32 [size = 36] `__guard_fids_table`
# CHECK-NEXT: type = 0x0022 (unsigned long), addr = 0003:0000
[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
--- !COFF
[llvm-pdbutil] Output the symbol offset when dumping. Type records have a unique type index, but symbol records do not. Instead, symbol records refer to other symbol records by referencing their offset in the symbol stream. In a sense this is the analogue of the TypeIndex, but we are not printing it in the dumper. Printing it not only gives us more useful information when manually investigating the contents of a PDB, but also allows us to write better tests by enabling us to verify that fields that reference other symbol records do so correctly. Differential Revision: https://reviews.llvm.org/D34906 llvm-svn: 306890
2017-07-01 05:35:00 +08:00
header:
[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
Machine: IMAGE_FILE_MACHINE_AMD64
Characteristics: [ ]
[llvm-pdbutil] Output the symbol offset when dumping. Type records have a unique type index, but symbol records do not. Instead, symbol records refer to other symbol records by referencing their offset in the symbol stream. In a sense this is the analogue of the TypeIndex, but we are not printing it in the dumper. Printing it not only gives us more useful information when manually investigating the contents of a PDB, but also allows us to write better tests by enabling us to verify that fields that reference other symbol records do so correctly. Differential Revision: https://reviews.llvm.org/D34906 llvm-svn: 306890
2017-07-01 05:35:00 +08:00
sections:
[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
- Name: '.debug$S'
Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_MEM_DISCARDABLE, IMAGE_SCN_MEM_READ ]
Alignment: 1
[llvm-pdbutil] Output the symbol offset when dumping. Type records have a unique type index, but symbol records do not. Instead, symbol records refer to other symbol records by referencing their offset in the symbol stream. In a sense this is the analogue of the TypeIndex, but we are not printing it in the dumper. Printing it not only gives us more useful information when manually investigating the contents of a PDB, but also allows us to write better tests by enabling us to verify that fields that reference other symbol records do so correctly. Differential Revision: https://reviews.llvm.org/D34906 llvm-svn: 306890
2017-07-01 05:35:00 +08:00
Subsections:
[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
- !Symbols
[llvm-pdbutil] Output the symbol offset when dumping. Type records have a unique type index, but symbol records do not. Instead, symbol records refer to other symbol records by referencing their offset in the symbol stream. In a sense this is the analogue of the TypeIndex, but we are not printing it in the dumper. Printing it not only gives us more useful information when manually investigating the contents of a PDB, but also allows us to write better tests by enabling us to verify that fields that reference other symbol records do so correctly. Differential Revision: https://reviews.llvm.org/D34906 llvm-svn: 306890
2017-07-01 05:35:00 +08:00
Records:
[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
- Kind: S_GDATA32
[llvm-pdbutil] Output the symbol offset when dumping. Type records have a unique type index, but symbol records do not. Instead, symbol records refer to other symbol records by referencing their offset in the symbol stream. In a sense this is the analogue of the TypeIndex, but we are not printing it in the dumper. Printing it not only gives us more useful information when manually investigating the contents of a PDB, but also allows us to write better tests by enabling us to verify that fields that reference other symbol records do so correctly. Differential Revision: https://reviews.llvm.org/D34906 llvm-svn: 306890
2017-07-01 05:35:00 +08:00
DataSym:
[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
Type: 34
DisplayName: __guard_fids_table
- !StringTable
[llvm-pdbutil] Output the symbol offset when dumping. Type records have a unique type index, but symbol records do not. Instead, symbol records refer to other symbol records by referencing their offset in the symbol stream. In a sense this is the analogue of the TypeIndex, but we are not printing it in the dumper. Printing it not only gives us more useful information when manually investigating the contents of a PDB, but also allows us to write better tests by enabling us to verify that fields that reference other symbol records do so correctly. Differential Revision: https://reviews.llvm.org/D34906 llvm-svn: 306890
2017-07-01 05:35:00 +08:00
Strings:
Relocations:
[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
- VirtualAddress: 20
SymbolName: __guard_fids_table
Type: IMAGE_REL_AMD64_SECREL
- VirtualAddress: 24
SymbolName: __guard_fids_table
Type: IMAGE_REL_AMD64_SECTION
- Name: '.text$mn'
Characteristics: [ IMAGE_SCN_CNT_CODE, IMAGE_SCN_MEM_EXECUTE, IMAGE_SCN_MEM_READ ]
Alignment: 16
SectionData: 488D0500000000C3
[llvm-pdbutil] Output the symbol offset when dumping. Type records have a unique type index, but symbol records do not. Instead, symbol records refer to other symbol records by referencing their offset in the symbol stream. In a sense this is the analogue of the TypeIndex, but we are not printing it in the dumper. Printing it not only gives us more useful information when manually investigating the contents of a PDB, but also allows us to write better tests by enabling us to verify that fields that reference other symbol records do so correctly. Differential Revision: https://reviews.llvm.org/D34906 llvm-svn: 306890
2017-07-01 05:35:00 +08:00
Relocations:
[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
- VirtualAddress: 3
SymbolName: __guard_fids_table
Type: IMAGE_REL_AMD64_REL32
[llvm-pdbutil] Output the symbol offset when dumping. Type records have a unique type index, but symbol records do not. Instead, symbol records refer to other symbol records by referencing their offset in the symbol stream. In a sense this is the analogue of the TypeIndex, but we are not printing it in the dumper. Printing it not only gives us more useful information when manually investigating the contents of a PDB, but also allows us to write better tests by enabling us to verify that fields that reference other symbol records do so correctly. Differential Revision: https://reviews.llvm.org/D34906 llvm-svn: 306890
2017-07-01 05:35:00 +08:00
symbols:
[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
- Name: '.debug$S'
Value: 0
SectionNumber: 1
SimpleType: IMAGE_SYM_TYPE_NULL
ComplexType: IMAGE_SYM_DTYPE_NULL
StorageClass: IMAGE_SYM_CLASS_STATIC
[llvm-pdbutil] Output the symbol offset when dumping. Type records have a unique type index, but symbol records do not. Instead, symbol records refer to other symbol records by referencing their offset in the symbol stream. In a sense this is the analogue of the TypeIndex, but we are not printing it in the dumper. Printing it not only gives us more useful information when manually investigating the contents of a PDB, but also allows us to write better tests by enabling us to verify that fields that reference other symbol records do so correctly. Differential Revision: https://reviews.llvm.org/D34906 llvm-svn: 306890
2017-07-01 05:35:00 +08:00
SectionDefinition:
[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
Length: 372
NumberOfRelocations: 6
NumberOfLinenumbers: 0
CheckSum: 0
Number: 0
- Name: '.text$mn'
Value: 0
SectionNumber: 2
SimpleType: IMAGE_SYM_TYPE_NULL
ComplexType: IMAGE_SYM_DTYPE_NULL
StorageClass: IMAGE_SYM_CLASS_STATIC
[llvm-pdbutil] Output the symbol offset when dumping. Type records have a unique type index, but symbol records do not. Instead, symbol records refer to other symbol records by referencing their offset in the symbol stream. In a sense this is the analogue of the TypeIndex, but we are not printing it in the dumper. Printing it not only gives us more useful information when manually investigating the contents of a PDB, but also allows us to write better tests by enabling us to verify that fields that reference other symbol records do so correctly. Differential Revision: https://reviews.llvm.org/D34906 llvm-svn: 306890
2017-07-01 05:35:00 +08:00
SectionDefinition:
[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
Length: 8
NumberOfRelocations: 1
NumberOfLinenumbers: 0
CheckSum: 1092178131
Number: 0
- Name: main
Value: 0
SectionNumber: 2
SimpleType: IMAGE_SYM_TYPE_NULL
ComplexType: IMAGE_SYM_DTYPE_FUNCTION
StorageClass: IMAGE_SYM_CLASS_EXTERNAL
- Name: __guard_fids_table
Value: 0
SectionNumber: 0
SimpleType: IMAGE_SYM_TYPE_NULL
ComplexType: IMAGE_SYM_DTYPE_NULL
StorageClass: IMAGE_SYM_CLASS_EXTERNAL
...