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/rsds.test

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

237 lines
7.5 KiB
Plaintext
Raw Normal View History

[test] Replace `yaml2obj >` with `yaml2obj -o` and remove unneeded input redirection
2020-08-21 06:00:25 +08:00
# RUN: yaml2obj %s -o %t.obj
COFF: add beginnings of debug directory creation The IMAGE_FILE_HEADER structure contains a (RVA, size) to an array of COFF_DEBUG_DIRECTORY records. Each one of these records contains an RVA to a OMF Debug Directory. These OMF debug directories are derived into newer types such as PDB70, PDB20, etc. This constructs a PDB70 structure which will allow us to associate a GUID with a build to actually tie debug information. llvm-svn: 280012
2016-08-30 05:20:46 +08:00
[LLD COFF/PDB] Incrementally update the build id. Previously, our algorithm to compute a build id involved hashing the executable and storing that as the GUID in the CV Debug Record chunk, and setting the age to 1. This breaks down in one very obvious case: a user adds some newlines to a file, rebuilds, but changes nothing else. This causes new line information and new file checksums to get written to the PDB, meaning that the debug info is different, but the generated code would be the same, so we would write the same build over again with an age of 1. Anyone using a symbol cache would have a problem now, because the debugger would open the executable, look at the age and guid, find a matching PDB in the symbol cache and then load it. It would never copy the new PDB to the symbol cache. This patch implements the canonical Windows algorithm for updating a build id, which is to check the existing executable first, and re-use an existing GUID while bumping the age if it already exists. Differential Revision: https://reviews.llvm.org/D36758 llvm-svn: 310961
2017-08-16 05:31:41 +08:00
# RUN: rm -f %t.dll %t.pdb
lld-link: Set PDB GUID to hash of PDB contents instead of to a random byte sequence. Previously, lld-link would use a random byte sequence as the PDB GUID. Instead, use a hash of the PDB file contents. To not disturb llvm-pdbutil pdb2yaml, the hash generation is an opt-in feature on InfoStreamBuilder and ldb/COFF/PDB.cpp always sets it. Since writing the PDB computes this ID which also goes in the exe, the PDB writing code now must be called before writeBuildId(). writeBuildId() for that reason is no longer included in the "Code Layout" timer. Since the PDB GUID is now a function of the PDB contents, the PDB Age is always set to 1. There was a long comment above loadExistingBuildId (now gone) about how not changing the GUID and only incrementing the age was important, but according to the discussion in PR35914 that comment was incorrect. Differential Revision: https://reviews.llvm.org/D51956 llvm-svn: 342334
2018-09-16 02:37:22 +08:00
# RUN: lld-link /debug /pdbaltpath:test.pdb /dll /out:%t.dll /entry:DllMain %t.obj
[test] Change llvm-readobj -long-option to --long-option or well-known short options. NFC Also change some options that have different semantics (cause confusion) in llvm-readelf mode: -s => -S -t => --symbols -sd => --section-data llvm-svn: 359651
2019-05-01 13:49:01 +08:00
# RUN: llvm-readobj --coff-debug-directory %t.dll > %t.1.txt
lld-link: Set PDB GUID to hash of PDB contents instead of to a random byte sequence. Previously, lld-link would use a random byte sequence as the PDB GUID. Instead, use a hash of the PDB file contents. To not disturb llvm-pdbutil pdb2yaml, the hash generation is an opt-in feature on InfoStreamBuilder and ldb/COFF/PDB.cpp always sets it. Since writing the PDB computes this ID which also goes in the exe, the PDB writing code now must be called before writeBuildId(). writeBuildId() for that reason is no longer included in the "Code Layout" timer. Since the PDB GUID is now a function of the PDB contents, the PDB Age is always set to 1. There was a long comment above loadExistingBuildId (now gone) about how not changing the GUID and only incrementing the age was important, but according to the discussion in PR35914 that comment was incorrect. Differential Revision: https://reviews.llvm.org/D51956 llvm-svn: 342334
2018-09-16 02:37:22 +08:00
# RUN: lld-link /debug /pdbaltpath:test.pdb /dll /out:%t.dll /entry:DllMain %t.obj
[test] Change llvm-readobj -long-option to --long-option or well-known short options. NFC Also change some options that have different semantics (cause confusion) in llvm-readelf mode: -s => -S -t => --symbols -sd => --section-data llvm-svn: 359651
2019-05-01 13:49:01 +08:00
# RUN: llvm-readobj --coff-debug-directory %t.dll > %t.2.txt
[LLD COFF/PDB] Incrementally update the build id. Previously, our algorithm to compute a build id involved hashing the executable and storing that as the GUID in the CV Debug Record chunk, and setting the age to 1. This breaks down in one very obvious case: a user adds some newlines to a file, rebuilds, but changes nothing else. This causes new line information and new file checksums to get written to the PDB, meaning that the debug info is different, but the generated code would be the same, so we would write the same build over again with an age of 1. Anyone using a symbol cache would have a problem now, because the debugger would open the executable, look at the age and guid, find a matching PDB in the symbol cache and then load it. It would never copy the new PDB to the symbol cache. This patch implements the canonical Windows algorithm for updating a build id, which is to check the existing executable first, and re-use an existing GUID while bumping the age if it already exists. Differential Revision: https://reviews.llvm.org/D36758 llvm-svn: 310961
2017-08-16 05:31:41 +08:00
# RUN: cat %t.1.txt %t.2.txt | FileCheck %s
COFF: add beginnings of debug directory creation The IMAGE_FILE_HEADER structure contains a (RVA, size) to an array of COFF_DEBUG_DIRECTORY records. Each one of these records contains an RVA to a OMF Debug Directory. These OMF debug directories are derived into newer types such as PDB70, PDB20, etc. This constructs a PDB70 structure which will allow us to associate a GUID with a build to actually tie debug information. llvm-svn: 280012
2016-08-30 05:20:46 +08:00
[LLD COFF/PDB] Incrementally update the build id. Previously, our algorithm to compute a build id involved hashing the executable and storing that as the GUID in the CV Debug Record chunk, and setting the age to 1. This breaks down in one very obvious case: a user adds some newlines to a file, rebuilds, but changes nothing else. This causes new line information and new file checksums to get written to the PDB, meaning that the debug info is different, but the generated code would be the same, so we would write the same build over again with an age of 1. Anyone using a symbol cache would have a problem now, because the debugger would open the executable, look at the age and guid, find a matching PDB in the symbol cache and then load it. It would never copy the new PDB to the symbol cache. This patch implements the canonical Windows algorithm for updating a build id, which is to check the existing executable first, and re-use an existing GUID while bumping the age if it already exists. Differential Revision: https://reviews.llvm.org/D36758 llvm-svn: 310961
2017-08-16 05:31:41 +08:00
# RUN: rm -f %t.dll %t.pdb
COFF: Implement /pdbaltpath flag. I needed to revert r330223 because we were embedding an absolute PDB path in the .rdata section, which ended up being laid out before the .idata section and affecting its RVAs. This flag will let us control the embedded path. Differential Revision: https://reviews.llvm.org/D45747 llvm-svn: 330232
2018-04-18 07:28:38 +08:00
# RUN: lld-link /debug /pdb:%t1.pdb /dll /out:%t.dll /entry:DllMain %t.obj
[test] Change llvm-readobj -long-option to --long-option or well-known short options. NFC Also change some options that have different semantics (cause confusion) in llvm-readelf mode: -s => -S -t => --symbols -sd => --section-data llvm-svn: 359651
2019-05-01 13:49:01 +08:00
# RUN: llvm-readobj --coff-debug-directory %t.dll > %t.3.txt
COFF: Implement /pdbaltpath flag. I needed to revert r330223 because we were embedding an absolute PDB path in the .rdata section, which ended up being laid out before the .idata section and affecting its RVAs. This flag will let us control the embedded path. Differential Revision: https://reviews.llvm.org/D45747 llvm-svn: 330232
2018-04-18 07:28:38 +08:00
# RUN: lld-link /debug /pdb:%t2.pdb /dll /out:%t.dll /entry:DllMain %t.obj
[test] Change llvm-readobj -long-option to --long-option or well-known short options. NFC Also change some options that have different semantics (cause confusion) in llvm-readelf mode: -s => -S -t => --symbols -sd => --section-data llvm-svn: 359651
2019-05-01 13:49:01 +08:00
# RUN: llvm-readobj --coff-debug-directory %t.dll > %t.4.txt
lld-link: Set PDB GUID to hash of PDB contents instead of to a random byte sequence. Previously, lld-link would use a random byte sequence as the PDB GUID. Instead, use a hash of the PDB file contents. To not disturb llvm-pdbutil pdb2yaml, the hash generation is an opt-in feature on InfoStreamBuilder and ldb/COFF/PDB.cpp always sets it. Since writing the PDB computes this ID which also goes in the exe, the PDB writing code now must be called before writeBuildId(). writeBuildId() for that reason is no longer included in the "Code Layout" timer. Since the PDB GUID is now a function of the PDB contents, the PDB Age is always set to 1. There was a long comment above loadExistingBuildId (now gone) about how not changing the GUID and only incrementing the age was important, but according to the discussion in PR35914 that comment was incorrect. Differential Revision: https://reviews.llvm.org/D51956 llvm-svn: 342334
2018-09-16 02:37:22 +08:00
# RUN: cat %t.3.txt %t.4.txt | FileCheck --check-prefix TWOPDBS %s
COFF: add beginnings of debug directory creation The IMAGE_FILE_HEADER structure contains a (RVA, size) to an array of COFF_DEBUG_DIRECTORY records. Each one of these records contains an RVA to a OMF Debug Directory. These OMF debug directories are derived into newer types such as PDB70, PDB20, etc. This constructs a PDB70 structure which will allow us to associate a GUID with a build to actually tie debug information. llvm-svn: 280012
2016-08-30 05:20:46 +08:00
lld-link: Write an empty "repro" debug directory entry if /Brepro is passed If the coff timestamp is set to a hash, like lld-link does if /Brepro is passed, the coff spec suggests that a IMAGE_DEBUG_TYPE_REPRO entry is in the debug directory. This lets lld-link write such a section. Fixes PR38429, see bug for details. Differential Revision: https://reviews.llvm.org/D51652 llvm-svn: 341486
2018-09-06 02:02:43 +08:00
# RUN: rm -f %t.dll %t.pdb
# RUN: lld-link /Brepro /dll /out:%t.dll /entry:DllMain %t.obj
[test] Change llvm-readobj -long-option to --long-option or well-known short options. NFC Also change some options that have different semantics (cause confusion) in llvm-readelf mode: -s => -S -t => --symbols -sd => --section-data llvm-svn: 359651
2019-05-01 13:49:01 +08:00
# RUN: llvm-readobj --coff-debug-directory %t.dll | FileCheck --check-prefix REPRO %s
lld-link: Write an empty "repro" debug directory entry if /Brepro is passed If the coff timestamp is set to a hash, like lld-link does if /Brepro is passed, the coff spec suggests that a IMAGE_DEBUG_TYPE_REPRO entry is in the debug directory. This lets lld-link write such a section. Fixes PR38429, see bug for details. Differential Revision: https://reviews.llvm.org/D51652 llvm-svn: 341486
2018-09-06 02:02:43 +08:00
# RUN: rm -f %t.dll %t.pdb
# RUN: lld-link /Brepro /debug /dll /out:%t.dll /entry:DllMain %t.obj
[test] Change llvm-readobj -long-option to --long-option or well-known short options. NFC Also change some options that have different semantics (cause confusion) in llvm-readelf mode: -s => -S -t => --symbols -sd => --section-data llvm-svn: 359651
2019-05-01 13:49:01 +08:00
# RUN: llvm-readobj --coff-debug-directory %t.dll | FileCheck --check-prefix REPRODEBUG %s
lld-link: Write an empty "repro" debug directory entry if /Brepro is passed If the coff timestamp is set to a hash, like lld-link does if /Brepro is passed, the coff spec suggests that a IMAGE_DEBUG_TYPE_REPRO entry is in the debug directory. This lets lld-link write such a section. Fixes PR38429, see bug for details. Differential Revision: https://reviews.llvm.org/D51652 llvm-svn: 341486
2018-09-06 02:02:43 +08:00
[COFF] Generate a codeview build id signature for MinGW even when not creating a PDB GNU ld, which doesn't generate PDBs, can optionally generate a build id by passing the --build-id option. LLD's MinGW frontend knows about this option but ignores it, as I had falsely assumed that LLD already generated build IDs even in those cases. If debug info is requested and no PDB path is set, generate a build id signature as a hash of the binary itself. This allows associating a binary to a minidump, even if debug info isn't written in PDB form by the linker. Differential Revision: https://reviews.llvm.org/D54828 llvm-svn: 347645
2018-11-27 17:20:55 +08:00
# RUN: rm -f %t.dll %t.pdb
# RUN: lld-link /lldmingw /debug:dwarf /dll /out:%t.dll /entry:DllMain %t.obj
[test] Change llvm-readobj -long-option to --long-option or well-known short options. NFC Also change some options that have different semantics (cause confusion) in llvm-readelf mode: -s => -S -t => --symbols -sd => --section-data llvm-svn: 359651
2019-05-01 13:49:01 +08:00
# RUN: llvm-readobj --coff-debug-directory %t.dll | FileCheck --check-prefix MINGW %s
[COFF] Generate a codeview build id signature for MinGW even when not creating a PDB GNU ld, which doesn't generate PDBs, can optionally generate a build id by passing the --build-id option. LLD's MinGW frontend knows about this option but ignores it, as I had falsely assumed that LLD already generated build IDs even in those cases. If debug info is requested and no PDB path is set, generate a build id signature as a hash of the binary itself. This allows associating a binary to a minidump, even if debug info isn't written in PDB form by the linker. Differential Revision: https://reviews.llvm.org/D54828 llvm-svn: 347645
2018-11-27 17:20:55 +08:00
[LLD COFF/PDB] Incrementally update the build id. Previously, our algorithm to compute a build id involved hashing the executable and storing that as the GUID in the CV Debug Record chunk, and setting the age to 1. This breaks down in one very obvious case: a user adds some newlines to a file, rebuilds, but changes nothing else. This causes new line information and new file checksums to get written to the PDB, meaning that the debug info is different, but the generated code would be the same, so we would write the same build over again with an age of 1. Anyone using a symbol cache would have a problem now, because the debugger would open the executable, look at the age and guid, find a matching PDB in the symbol cache and then load it. It would never copy the new PDB to the symbol cache. This patch implements the canonical Windows algorithm for updating a build id, which is to check the existing executable first, and re-use an existing GUID while bumping the age if it already exists. Differential Revision: https://reviews.llvm.org/D36758 llvm-svn: 310961
2017-08-16 05:31:41 +08:00
# CHECK: File: [[FILE:.*]].dll
COFF: add beginnings of debug directory creation The IMAGE_FILE_HEADER structure contains a (RVA, size) to an array of COFF_DEBUG_DIRECTORY records. Each one of these records contains an RVA to a OMF Debug Directory. These OMF debug directories are derived into newer types such as PDB70, PDB20, etc. This constructs a PDB70 structure which will allow us to associate a GUID with a build to actually tie debug information. llvm-svn: 280012
2016-08-30 05:20:46 +08:00
# CHECK: DebugDirectory [
# CHECK: DebugEntry {
# CHECK: Characteristics: 0x0
Resubmit "Write a hash of the executable into the PE timestamp fields." This fixes the broken tests that were causing failures. The tests before were verifying that the time stamp was 0, but now that we are actually writing a timestamp, I just removed the match against the timestamp value. llvm-svn: 327049
2018-03-09 03:33:47 +08:00
# CHECK: TimeDateStamp:
COFF: add beginnings of debug directory creation The IMAGE_FILE_HEADER structure contains a (RVA, size) to an array of COFF_DEBUG_DIRECTORY records. Each one of these records contains an RVA to a OMF Debug Directory. These OMF debug directories are derived into newer types such as PDB70, PDB20, etc. This constructs a PDB70 structure which will allow us to associate a GUID with a build to actually tie debug information. llvm-svn: 280012
2016-08-30 05:20:46 +08:00
# CHECK: MajorVersion: 0x0
# CHECK: MinorVersion: 0x0
# CHECK: Type: CodeView (0x2)
[PDB] Improve rsds test to check that we fill in the file offset as well as the RVA llvm-svn: 309902
2017-08-03 07:32:26 +08:00
# CHECK: SizeOfData: 0x{{[^0]}}
# CHECK: AddressOfRawData: 0x{{[^0]}}
# CHECK: PointerToRawData: 0x{{[^0]}}
COFF: add beginnings of debug directory creation The IMAGE_FILE_HEADER structure contains a (RVA, size) to an array of COFF_DEBUG_DIRECTORY records. Each one of these records contains an RVA to a OMF Debug Directory. These OMF debug directories are derived into newer types such as PDB70, PDB20, etc. This constructs a PDB70 structure which will allow us to associate a GUID with a build to actually tie debug information. llvm-svn: 280012
2016-08-30 05:20:46 +08:00
# CHECK: PDBInfo {
# CHECK: PDBSignature: 0x53445352
[LLD COFF/PDB] Incrementally update the build id. Previously, our algorithm to compute a build id involved hashing the executable and storing that as the GUID in the CV Debug Record chunk, and setting the age to 1. This breaks down in one very obvious case: a user adds some newlines to a file, rebuilds, but changes nothing else. This causes new line information and new file checksums to get written to the PDB, meaning that the debug info is different, but the generated code would be the same, so we would write the same build over again with an age of 1. Anyone using a symbol cache would have a problem now, because the debugger would open the executable, look at the age and guid, find a matching PDB in the symbol cache and then load it. It would never copy the new PDB to the symbol cache. This patch implements the canonical Windows algorithm for updating a build id, which is to check the existing executable first, and re-use an existing GUID while bumping the age if it already exists. Differential Revision: https://reviews.llvm.org/D36758 llvm-svn: 310961
2017-08-16 05:31:41 +08:00
# CHECK: PDBGUID: [[GUID:\(([A-Za-z0-9]{2} ?){16}\)]]
COFF: add beginnings of debug directory creation The IMAGE_FILE_HEADER structure contains a (RVA, size) to an array of COFF_DEBUG_DIRECTORY records. Each one of these records contains an RVA to a OMF Debug Directory. These OMF debug directories are derived into newer types such as PDB70, PDB20, etc. This constructs a PDB70 structure which will allow us to associate a GUID with a build to actually tie debug information. llvm-svn: 280012
2016-08-30 05:20:46 +08:00
# CHECK: PDBAge: 1
lld-link: Set PDB GUID to hash of PDB contents instead of to a random byte sequence. Previously, lld-link would use a random byte sequence as the PDB GUID. Instead, use a hash of the PDB file contents. To not disturb llvm-pdbutil pdb2yaml, the hash generation is an opt-in feature on InfoStreamBuilder and ldb/COFF/PDB.cpp always sets it. Since writing the PDB computes this ID which also goes in the exe, the PDB writing code now must be called before writeBuildId(). writeBuildId() for that reason is no longer included in the "Code Layout" timer. Since the PDB GUID is now a function of the PDB contents, the PDB Age is always set to 1. There was a long comment above loadExistingBuildId (now gone) about how not changing the GUID and only incrementing the age was important, but according to the discussion in PR35914 that comment was incorrect. Differential Revision: https://reviews.llvm.org/D51956 llvm-svn: 342334
2018-09-16 02:37:22 +08:00
# CHECK: PDBFileName: {{.*}}.pdb
COFF: add beginnings of debug directory creation The IMAGE_FILE_HEADER structure contains a (RVA, size) to an array of COFF_DEBUG_DIRECTORY records. Each one of these records contains an RVA to a OMF Debug Directory. These OMF debug directories are derived into newer types such as PDB70, PDB20, etc. This constructs a PDB70 structure which will allow us to associate a GUID with a build to actually tie debug information. llvm-svn: 280012
2016-08-30 05:20:46 +08:00
# CHECK: }
# CHECK: }
# CHECK: ]
[LLD COFF/PDB] Incrementally update the build id. Previously, our algorithm to compute a build id involved hashing the executable and storing that as the GUID in the CV Debug Record chunk, and setting the age to 1. This breaks down in one very obvious case: a user adds some newlines to a file, rebuilds, but changes nothing else. This causes new line information and new file checksums to get written to the PDB, meaning that the debug info is different, but the generated code would be the same, so we would write the same build over again with an age of 1. Anyone using a symbol cache would have a problem now, because the debugger would open the executable, look at the age and guid, find a matching PDB in the symbol cache and then load it. It would never copy the new PDB to the symbol cache. This patch implements the canonical Windows algorithm for updating a build id, which is to check the existing executable first, and re-use an existing GUID while bumping the age if it already exists. Differential Revision: https://reviews.llvm.org/D36758 llvm-svn: 310961
2017-08-16 05:31:41 +08:00
# CHECK: File: [[FILE]].dll
# CHECK: DebugDirectory [
# CHECK: DebugEntry {
# CHECK: Characteristics: 0x0
Resubmit "Write a hash of the executable into the PE timestamp fields." This fixes the broken tests that were causing failures. The tests before were verifying that the time stamp was 0, but now that we are actually writing a timestamp, I just removed the match against the timestamp value. llvm-svn: 327049
2018-03-09 03:33:47 +08:00
# CHECK: TimeDateStamp:
[LLD COFF/PDB] Incrementally update the build id. Previously, our algorithm to compute a build id involved hashing the executable and storing that as the GUID in the CV Debug Record chunk, and setting the age to 1. This breaks down in one very obvious case: a user adds some newlines to a file, rebuilds, but changes nothing else. This causes new line information and new file checksums to get written to the PDB, meaning that the debug info is different, but the generated code would be the same, so we would write the same build over again with an age of 1. Anyone using a symbol cache would have a problem now, because the debugger would open the executable, look at the age and guid, find a matching PDB in the symbol cache and then load it. It would never copy the new PDB to the symbol cache. This patch implements the canonical Windows algorithm for updating a build id, which is to check the existing executable first, and re-use an existing GUID while bumping the age if it already exists. Differential Revision: https://reviews.llvm.org/D36758 llvm-svn: 310961
2017-08-16 05:31:41 +08:00
# CHECK: MajorVersion: 0x0
# CHECK: MinorVersion: 0x0
# CHECK: Type: CodeView (0x2)
# CHECK: SizeOfData: 0x{{[^0]}}
# CHECK: AddressOfRawData: 0x{{[^0]}}
# CHECK: PointerToRawData: 0x{{[^0]}}
# CHECK: PDBInfo {
# CHECK: PDBSignature: 0x53445352
# CHECK: PDBGUID: [[GUID]]
lld-link: Set PDB GUID to hash of PDB contents instead of to a random byte sequence. Previously, lld-link would use a random byte sequence as the PDB GUID. Instead, use a hash of the PDB file contents. To not disturb llvm-pdbutil pdb2yaml, the hash generation is an opt-in feature on InfoStreamBuilder and ldb/COFF/PDB.cpp always sets it. Since writing the PDB computes this ID which also goes in the exe, the PDB writing code now must be called before writeBuildId(). writeBuildId() for that reason is no longer included in the "Code Layout" timer. Since the PDB GUID is now a function of the PDB contents, the PDB Age is always set to 1. There was a long comment above loadExistingBuildId (now gone) about how not changing the GUID and only incrementing the age was important, but according to the discussion in PR35914 that comment was incorrect. Differential Revision: https://reviews.llvm.org/D51956 llvm-svn: 342334
2018-09-16 02:37:22 +08:00
# CHECK: PDBAge: 1
# CHECK: PDBFileName: {{.*}}.pdb
[LLD COFF/PDB] Incrementally update the build id. Previously, our algorithm to compute a build id involved hashing the executable and storing that as the GUID in the CV Debug Record chunk, and setting the age to 1. This breaks down in one very obvious case: a user adds some newlines to a file, rebuilds, but changes nothing else. This causes new line information and new file checksums to get written to the PDB, meaning that the debug info is different, but the generated code would be the same, so we would write the same build over again with an age of 1. Anyone using a symbol cache would have a problem now, because the debugger would open the executable, look at the age and guid, find a matching PDB in the symbol cache and then load it. It would never copy the new PDB to the symbol cache. This patch implements the canonical Windows algorithm for updating a build id, which is to check the existing executable first, and re-use an existing GUID while bumping the age if it already exists. Differential Revision: https://reviews.llvm.org/D36758 llvm-svn: 310961
2017-08-16 05:31:41 +08:00
# CHECK: }
# CHECK: }
# CHECK: ]
COFF: add beginnings of debug directory creation The IMAGE_FILE_HEADER structure contains a (RVA, size) to an array of COFF_DEBUG_DIRECTORY records. Each one of these records contains an RVA to a OMF Debug Directory. These OMF debug directories are derived into newer types such as PDB70, PDB20, etc. This constructs a PDB70 structure which will allow us to associate a GUID with a build to actually tie debug information. llvm-svn: 280012
2016-08-30 05:20:46 +08:00
lld-link: Set PDB GUID to hash of PDB contents instead of to a random byte sequence. Previously, lld-link would use a random byte sequence as the PDB GUID. Instead, use a hash of the PDB file contents. To not disturb llvm-pdbutil pdb2yaml, the hash generation is an opt-in feature on InfoStreamBuilder and ldb/COFF/PDB.cpp always sets it. Since writing the PDB computes this ID which also goes in the exe, the PDB writing code now must be called before writeBuildId(). writeBuildId() for that reason is no longer included in the "Code Layout" timer. Since the PDB GUID is now a function of the PDB contents, the PDB Age is always set to 1. There was a long comment above loadExistingBuildId (now gone) about how not changing the GUID and only incrementing the age was important, but according to the discussion in PR35914 that comment was incorrect. Differential Revision: https://reviews.llvm.org/D51956 llvm-svn: 342334
2018-09-16 02:37:22 +08:00
# TWOPDBS: File: [[FILE:.*]].dll
# TWOPDBS: DebugDirectory [
# TWOPDBS: DebugEntry {
# TWOPDBS: Characteristics: 0x0
# TWOPDBS: TimeDateStamp:
# TWOPDBS: MajorVersion: 0x0
# TWOPDBS: MinorVersion: 0x0
# TWOPDBS: Type: CodeView (0x2)
# TWOPDBS: SizeOfData: 0x{{[^0]}}
# TWOPDBS: AddressOfRawData: 0x{{[^0]}}
# TWOPDBS: PointerToRawData: 0x{{[^0]}}
# TWOPDBS: PDBInfo {
# TWOPDBS: PDBSignature: 0x53445352
# TWOPDBS: PDBGUID: [[GUID:\(([A-Za-z0-9]{2} ?){16}\)]]
# TWOPDBS: PDBAge: 1
# TWOPDBS: PDBFileName: {{.*}}.pdb
# TWOPDBS: }
# TWOPDBS: }
# TWOPDBS: ]
# TWOPDBS: File: [[FILE]].dll
# TWOPDBS: DebugDirectory [
# TWOPDBS: DebugEntry {
# TWOPDBS: Characteristics: 0x0
# TWOPDBS: TimeDateStamp:
# TWOPDBS: MajorVersion: 0x0
# TWOPDBS: MinorVersion: 0x0
# TWOPDBS: Type: CodeView (0x2)
# TWOPDBS: SizeOfData: 0x{{[^0]}}
# TWOPDBS: AddressOfRawData: 0x{{[^0]}}
# TWOPDBS: PointerToRawData: 0x{{[^0]}}
# TWOPDBS: PDBInfo {
# TWOPDBS: PDBSignature: 0x53445352
# TWOPDBS-NOT: PDBGUID: [[GUID]]
# TWOPDBS: PDBAge: 1
# TWOPDBS: PDBFileName: {{.*}}.pdb
# TWOPDBS: }
# TWOPDBS: }
# TWOPDBS: ]
lld-link: Write an empty "repro" debug directory entry if /Brepro is passed If the coff timestamp is set to a hash, like lld-link does if /Brepro is passed, the coff spec suggests that a IMAGE_DEBUG_TYPE_REPRO entry is in the debug directory. This lets lld-link write such a section. Fixes PR38429, see bug for details. Differential Revision: https://reviews.llvm.org/D51652 llvm-svn: 341486
2018-09-06 02:02:43 +08:00
# REPRO: File: {{.*}}.dll
# REPRO: DebugDirectory [
# REPRO: DebugEntry {
# REPRO: Characteristics: 0x0
# REPRO: TimeDateStamp:
# REPRO: MajorVersion: 0x0
# REPRO: MinorVersion: 0x0
# REPRO: Type: Repro (0x10)
# REPRO: SizeOfData: 0x0
# REPRO: AddressOfRawData: 0x0
# REPRO: PointerToRawData: 0x0
# REPRO: }
# REPRO: ]
# REPRODEBUG: File: {{.*}}.dll
# REPRODEBUG: DebugDirectory [
# REPRODEBUG: DebugEntry {
# REPRODEBUG: Characteristics: 0x0
# REPRODEBUG: TimeDateStamp:
# REPRODEBUG: MajorVersion: 0x0
# REPRODEBUG: MinorVersion: 0x0
# REPRODEBUG: Type: CodeView (0x2)
# REPRODEBUG: SizeOfData: 0x{{[^0]}}
# REPRODEBUG: AddressOfRawData: 0x{{[^0]}}
# REPRODEBUG: PointerToRawData: 0x{{[^0]}}
# REPRODEBUG: PDBInfo {
# REPRODEBUG: PDBSignature: 0x53445352
# REPRODEBUG: PDBGUID:
# REPRODEBUG: PDBAge: 1
# REPRODEBUG: PDBFileName:
# REPRODEBUG: }
# REPRODEBUG: }
# REPRODEBUG: DebugEntry {
# REPRODEBUG: Characteristics: 0x0
# REPRODEBUG: TimeDateStamp:
# REPRODEBUG: MajorVersion: 0x0
# REPRODEBUG: MinorVersion: 0x0
# REPRODEBUG: Type: Repro (0x10)
# REPRODEBUG: SizeOfData: 0x0
# REPRODEBUG: AddressOfRawData: 0x0
# REPRODEBUG: PointerToRawData: 0x0
# REPRODEBUG: }
# REPRODEBUG: ]
[COFF] Generate a codeview build id signature for MinGW even when not creating a PDB GNU ld, which doesn't generate PDBs, can optionally generate a build id by passing the --build-id option. LLD's MinGW frontend knows about this option but ignores it, as I had falsely assumed that LLD already generated build IDs even in those cases. If debug info is requested and no PDB path is set, generate a build id signature as a hash of the binary itself. This allows associating a binary to a minidump, even if debug info isn't written in PDB form by the linker. Differential Revision: https://reviews.llvm.org/D54828 llvm-svn: 347645
2018-11-27 17:20:55 +08:00
# MINGW: File: {{.*}}.dll
# MINGW: DebugDirectory [
# MINGW: DebugEntry {
# MINGW: Characteristics: 0x0
# MINGW: TimeDateStamp:
# MINGW: MajorVersion: 0x0
# MINGW: MinorVersion: 0x0
# MINGW: Type: CodeView (0x2)
# MINGW: SizeOfData: 0x{{[^0]}}
# MINGW: AddressOfRawData: 0x{{[^0]}}
# MINGW: PointerToRawData: 0x{{[^0]}}
# MINGW: PDBInfo {
# MINGW: PDBSignature: 0x53445352
# MINGW: PDBGUID: [[GUID:\(([A-Za-z0-9]{2} ?){16}\)]]
# MINGW: PDBAge: 1
# MINGW: PDBFileName:
# MINGW: }
# MINGW: }
# MINGW: ]
COFF: add beginnings of debug directory creation The IMAGE_FILE_HEADER structure contains a (RVA, size) to an array of COFF_DEBUG_DIRECTORY records. Each one of these records contains an RVA to a OMF Debug Directory. These OMF debug directories are derived into newer types such as PDB70, PDB20, etc. This constructs a PDB70 structure which will allow us to associate a GUID with a build to actually tie debug information. llvm-svn: 280012
2016-08-30 05:20:46 +08:00
--- !COFF
header:
Machine: IMAGE_FILE_MACHINE_I386
Characteristics: [ ]
sections:
- Name: .text
Characteristics: [ IMAGE_SCN_CNT_CODE, IMAGE_SCN_MEM_EXECUTE, IMAGE_SCN_MEM_READ ]
Alignment: 4
SectionData: 31C0C3
- Name: .data
Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_MEM_READ, IMAGE_SCN_MEM_WRITE ]
Alignment: 4
SectionData: ''
- Name: .bss
Characteristics: [ IMAGE_SCN_CNT_UNINITIALIZED_DATA, IMAGE_SCN_MEM_READ, IMAGE_SCN_MEM_WRITE ]
Alignment: 4
SectionData: ''
symbols:
- Name: .text
Value: 0
SectionNumber: 1
SimpleType: IMAGE_SYM_TYPE_NULL
ComplexType: IMAGE_SYM_DTYPE_NULL
StorageClass: IMAGE_SYM_CLASS_STATIC
SectionDefinition:
Length: 3
NumberOfRelocations: 0
NumberOfLinenumbers: 0
CheckSum: 3963538403
Number: 1
- Name: .data
Value: 0
SectionNumber: 2
SimpleType: IMAGE_SYM_TYPE_NULL
ComplexType: IMAGE_SYM_DTYPE_NULL
StorageClass: IMAGE_SYM_CLASS_STATIC
SectionDefinition:
Length: 0
NumberOfRelocations: 0
NumberOfLinenumbers: 0
CheckSum: 0
Number: 2
- Name: .bss
Value: 0
SectionNumber: 3
SimpleType: IMAGE_SYM_TYPE_NULL
ComplexType: IMAGE_SYM_DTYPE_NULL
StorageClass: IMAGE_SYM_CLASS_STATIC
SectionDefinition:
Length: 0
NumberOfRelocations: 0
NumberOfLinenumbers: 0
CheckSum: 0
Number: 3
- Name: '@feat.00'
Value: 1
SectionNumber: -1
SimpleType: IMAGE_SYM_TYPE_NULL
ComplexType: IMAGE_SYM_DTYPE_NULL
StorageClass: IMAGE_SYM_CLASS_STATIC
- Name: _DllMain
Value: 0
SectionNumber: 1
SimpleType: IMAGE_SYM_TYPE_NULL
ComplexType: IMAGE_SYM_DTYPE_FUNCTION
StorageClass: IMAGE_SYM_CLASS_EXTERNAL
...