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

284 lines
15 KiB
Plaintext
Raw Normal View History

PDB: Merge type info. This patch is to merge type info in multiple .debug$T sections. One mystery that needs to be solved is that it is not clear how the MSVC linker uses TPI and IPI streams. Both streams contain type info, and it is not obvious what kind of record should go which. dumppdb command in microsoft-pdb repository prints out IPI stream contents as "IDs" and TPI stream as "TYPES", but looks like the tool don't really care about which stream type recrods were read from. For now, in this patch, I emit all type records to TPI stream. It might just work with other tools. If not, we need to investigate it more. llvm-svn: 291739
2017-01-12 11:09:25 +08:00
# RUN: yaml2obj < %p/Inputs/pdb1.yaml > %t1.obj
# RUN: yaml2obj < %p/Inputs/pdb2.yaml > %t2.obj
[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
Create a TPI stream only when /debugpdb is given. Adding type records to TPI stream is too time consuming. It is reported that linking chrome_child.dll took 5 minutes. llvm-svn: 289330
2016-12-11 01:23:23 +08:00
# RUN: lld-link /debug /pdb:%t.pdb /dll /out:%t.dll /entry:main /nodefaultlib \
[COFF] Fix interaction between /DEBUG and /PDB When /DEBUG is not specified, /PDB should be ignored. When /DEBUG is specified, a PDB should be output regardless of whether or not /PDB is specified. /PDB just overrides the default name. This patch implements this behavior, and adds some tests, while also removing a dead option /DEBUGPDB which was unused in any code. Differential Revision: https://reviews.llvm.org/D33302 llvm-svn: 303352
2017-05-18 23:15:10 +08:00
# RUN: %t1.obj %t2.obj
PDB: Merge type info. This patch is to merge type info in multiple .debug$T sections. One mystery that needs to be solved is that it is not clear how the MSVC linker uses TPI and IPI streams. Both streams contain type info, and it is not obvious what kind of record should go which. dumppdb command in microsoft-pdb repository prints out IPI stream contents as "IDs" and TPI stream as "TYPES", but looks like the tool don't really care about which stream type recrods were read from. For now, in this patch, I emit all type records to TPI stream. It might just work with other tools. If not, we need to investigate it more. llvm-svn: 291739
2017-01-12 11:09:25 +08:00
Rename llvm-pdbdump -> llvm-pdbutil. This is to reflect the evolving nature of the tool as being useful for more than just dumping PDBs, as it can do many other things. Differential Revision: https://reviews.llvm.org/D34062 llvm-svn: 305106
2017-06-10 04:46:17 +08:00
# RUN: llvm-pdbutil pdb2yaml -stream-metadata -stream-directory -pdb-stream \
Add type records to TPI stream. I don't think the data I add to a TPI stream in this patch is correct, but at least it can be displayed using llvm-pdbdump. Until I add more streams to a PDB file, I'm not able to know whether the data will be accepted by MSVC tools or not. llvm-svn: 289183
2016-12-09 12:46:54 +08:00
# RUN: -dbi-stream -ipi-stream -tpi-stream %t.pdb | FileCheck %s
Check /pdb output using llvm-pdbdump. test/COFF/rsds.test checks only RSDS directory in a DLL and didn't check the validity of the PDF file produced. (Technically the produced PDB is not valid because it is really a stub, but this test is still good to have.) llvm-svn: 281678
2016-09-16 07:14:40 +08:00
[llvm-pdbutil] Dump image section headers. Image section headers are stored in the DBI stream, but we had no way to dump them. This patch adds dumping support, along with some tests that LLD actually dumps them correctly. Differential Revision: https://reviews.llvm.org/D36332 llvm-svn: 310107
2017-08-05 04:02:38 +08:00
# RUN: llvm-pdbutil dump -modules -section-map -section-contribs -section-headers \
[PDB] Write public symbol records and the publics hash table Summary: MSVC link.exe records all external symbol names in the publics stream. It provides similar functionality to an ELF .symtab. Reviewers: zturner, ruiu Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D35871 llvm-svn: 309303
2017-07-28 02:25:59 +08:00
# RUN: -publics -public-extras -types -ids -type-extras -id-extras %t.pdb \
# RUN: | FileCheck -check-prefix RAW %s
[PDB] Re-add RAW FileCheck testing to pdb.test Update the expected output to match the current llvm-pdbdump raw output. llvm-svn: 299793
2017-04-08 02:38:38 +08:00
Check /pdb output using llvm-pdbdump. test/COFF/rsds.test checks only RSDS directory in a DLL and didn't check the validity of the PDF file produced. (Technically the produced PDB is not valid because it is really a stub, but this test is still good to have.) llvm-svn: 281678
2016-09-16 07:14:40 +08:00
# CHECK: MSF:
# CHECK-NEXT: SuperBlock:
Use functions in DebugInfoPDB to create dummy PDB file. I don't think we are creating valid PDB file here, but it is okay because we have never created valid PDBs before. llvm-svn: 281704
2016-09-16 12:32:33 +08:00
# CHECK-NEXT: BlockSize: 4096
[MSF] Default to FPM2, and always mark FPM pages allocated. There are two FPMs in an MSF file, the idea being that for incremental updates you can write to the alternate one and then atomically swap them on commit. LLVM defaulted to using FPM1 on the first commit, but this differs from Microsoft's behavior which is to default to using FPM2 on the first commit. To eliminate some byte-level file differences, this patch changes LLVM's default to also be FPM2. Additionally, LLVM was trying to be "smart" about marking FPM pages allocated. In addition to marking every page belonging to the alternate FPM as unallocated, LLVM also marked pages at the end of the main FPM which were not needed as unallocated. In order to match the behavior of Microsoft-generated PDBs, we now always mark every FPM block as allocated, regardless of whether it is in the main FPM or the alt FPM, and regardless of whether or not it describes blocks which are actually in the file. This has the side benefit of simplifying our code. llvm-svn: 328812
2018-03-30 02:34:15 +08:00
# CHECK-NEXT: FreeBlockMap: 2
Fix lld pdb test. It was assuming various things about the PDB like file size which are going to be too high maintenance to maintain in a test. llvm-svn: 297908
2017-03-16 06:58:10 +08:00
# CHECK-NEXT: NumBlocks:
# CHECK-NEXT: NumDirectoryBytes:
Use functions in DebugInfoPDB to create dummy PDB file. I don't think we are creating valid PDB file here, but it is okay because we have never created valid PDBs before. llvm-svn: 281704
2016-09-16 12:32:33 +08:00
# CHECK-NEXT: Unknown1: 0
Fix lld pdb test. It was assuming various things about the PDB like file size which are going to be too high maintenance to maintain in a test. llvm-svn: 297908
2017-03-16 06:58:10 +08:00
# CHECK-NEXT: BlockMapAddr:
# CHECK-NEXT: NumDirectoryBlocks:
# CHECK-NEXT: DirectoryBlocks:
Resubmit "[llvm-pdbutil] rewrite the "raw" output style." This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
2017-06-16 06:24:24 +08:00
# CHECK-NEXT: NumStreams:
# CHECK-NEXT: FileSize:
# CHECK-NEXT: StreamSizes:
[PDB] Start emitting source file and line information Summary: This is a first step towards getting line info to show up in VS and windbg. So far, only llvm-pdbutil can parse the PDBs that we produce. cvdump doesn't like something about our file checksum tables. I'll have to dig into that next. This patch adds a new DebugSubsectionRecordBuilder which takes bytes directly from some other producer, such as a linker, and sticks it into the PDB. Line tables only need to be relocated. No data needs to be rewritten. File checksums and string tables, on the other hand, need to be re-done. Reviewers: zturner, ruiu Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D34257 llvm-svn: 305713
2017-06-20 01:21:45 +08:00
# CHECK: StreamMap:
Fix lld pdb test. It was assuming various things about the PDB like file size which are going to be too high maintenance to maintain in a test. llvm-svn: 297908
2017-03-16 06:58:10 +08:00
# CHECK: PdbStream:
Add type records to TPI stream. I don't think the data I add to a TPI stream in this patch is correct, but at least it can be displayed using llvm-pdbdump. Until I add more streams to a PDB file, I'm not able to know whether the data will be accepted by MSVC tools or not. llvm-svn: 289183
2016-12-09 12:46:54 +08:00
# CHECK-NEXT: Age: 1
PDB: Merge type info. This patch is to merge type info in multiple .debug$T sections. One mystery that needs to be solved is that it is not clear how the MSVC linker uses TPI and IPI streams. Both streams contain type info, and it is not obvious what kind of record should go which. dumppdb command in microsoft-pdb repository prints out IPI stream contents as "IDs" and TPI stream as "TYPES", but looks like the tool don't really care about which stream type recrods were read from. For now, in this patch, I emit all type records to TPI stream. It might just work with other tools. If not, we need to investigate it more. llvm-svn: 291739
2017-01-12 11:09:25 +08:00
# CHECK-NEXT: Guid:
[PDB] More changes to bring lld PDBs to parity with MSVC. 1) Don't write a /src/headerblock stream. This appears to be written conditionally by MSVC, but it's not clear what the condition is. For now, just remove it since we dont' know what it is anyway and the particular pdb we've checked in for the test doesn't have one. 2) Write a valid timestamp for the PDB file signature. This leads to non-reproducible builds, but it matches the default behavior of link, so it should be out default as well. If we need reproducibility, we should add a separate command line option for it that is off by default. 3) Write an empty FPO stream. MSVC seems to always write an FPO stream. This change makes the stream directory match up, although we still need to make the contents of the FPO stream match. llvm-svn: 307436
2017-07-08 04:25:39 +08:00
# CHECK-NEXT: Signature:
Slightly better fix for dealing with no-id-stream PDBs. The last fix required the user to manually add the required feature. This caused an LLD test to fail because I failed to update LLD. In practice we can hide this logic so it can just be transparently added when we write the PDB. llvm-svn: 305236
2017-06-13 05:46:51 +08:00
# CHECK-NEXT: Features: [ VC140 ]
Add type records to TPI stream. I don't think the data I add to a TPI stream in this patch is correct, but at least it can be displayed using llvm-pdbdump. Until I add more streams to a PDB file, I'm not able to know whether the data will be accepted by MSVC tools or not. llvm-svn: 289183
2016-12-09 12:46:54 +08:00
# CHECK-NEXT: Version: VC70
# CHECK-NEXT: DbiStream:
Fix some differences between lld and MSVC generated PDBs. A couple of things were different about our generated PDBs. 1) We were outputting the wrong Version on the PDB Stream. The version we were setting was newer than what MSVC is setting. It's not clear what the implications are, but we change LLD to use PdbImplVC70, as MSVC does. 2) For the optional debug stream indices in the DBI Stream, we were outputting 0 to mean "the stream is not present". MSVC outputs uint16_t(-1), which is the "correct" way to specify that a stream is not present. So we fix that as well. 3) We were setting the PDB Stream signature to 0. This is supposed to be the result of calling time(nullptr). Although this leads to non-deterministic builds, a better way to solve that is by having a command line option explicitly for generating a reproducible build, and have the default behavior of lld-link match the default behavior of link. To test this, I'm making use of the new and improved `pdb diff` sub command. To make it suitable for writing tests against, I had to modify the diff subcommand slightly to print less verbose output. Previously it would always print | <column> | <value1> | <value2> | which is quite verbose, and the values are fragile. All we really want to know is "did we produce the same value as link?" So I added command line options to print a single character representing the result status (different, identical, equivalent), and another to hide the value display. Note that just inspecting the diff output used to write the test, you can see some things that are obviously wrong. That is just reflective of the fact that this is the state of affairs today, not that we're asserting that this is "correct". We can use this as a starting point to discover differences, fix them, and update the test. Differential Revision: https://reviews.llvm.org/D35086 llvm-svn: 307422
2017-07-08 02:45:56 +08:00
# CHECK-NEXT: VerHeader: V70
Add type records to TPI stream. I don't think the data I add to a TPI stream in this patch is correct, but at least it can be displayed using llvm-pdbdump. Until I add more streams to a PDB file, I'm not able to know whether the data will be accepted by MSVC tools or not. llvm-svn: 289183
2016-12-09 12:46:54 +08:00
# CHECK-NEXT: Age: 1
Resubmit "Fix some incorrect fields in our generated PDBs." This fixes the failing tests. They simply hadn't been updated to match the new output resulting from this patch. llvm-svn: 330145
2018-04-17 02:17:13 +08:00
# CHECK-NEXT: BuildNumber: 36363
Add type records to TPI stream. I don't think the data I add to a TPI stream in this patch is correct, but at least it can be displayed using llvm-pdbdump. Until I add more streams to a PDB file, I'm not able to know whether the data will be accepted by MSVC tools or not. llvm-svn: 289183
2016-12-09 12:46:54 +08:00
# CHECK-NEXT: PdbDllVersion: 0
# CHECK-NEXT: PdbDllRbld: 0
# CHECK-NEXT: Flags: 0
Resubmit "Fix some incorrect fields in our generated PDBs." This fixes the failing tests. They simply hadn't been updated to match the new output resulting from this patch. llvm-svn: 330145
2018-04-17 02:17:13 +08:00
# CHECK-NEXT: MachineType: Amd64
Add type records to TPI stream. I don't think the data I add to a TPI stream in this patch is correct, but at least it can be displayed using llvm-pdbdump. Until I add more streams to a PDB file, I'm not able to know whether the data will be accepted by MSVC tools or not. llvm-svn: 289183
2016-12-09 12:46:54 +08:00
# CHECK-NEXT: TpiStream:
# CHECK-NEXT: Version: VC80
# CHECK-NEXT: Records:
# CHECK-NEXT: - Kind: LF_ARGLIST
# CHECK-NEXT: ArgList:
PDB: Merge type info. This patch is to merge type info in multiple .debug$T sections. One mystery that needs to be solved is that it is not clear how the MSVC linker uses TPI and IPI streams. Both streams contain type info, and it is not obvious what kind of record should go which. dumppdb command in microsoft-pdb repository prints out IPI stream contents as "IDs" and TPI stream as "TYPES", but looks like the tool don't really care about which stream type recrods were read from. For now, in this patch, I emit all type records to TPI stream. It might just work with other tools. If not, we need to investigate it more. llvm-svn: 291739
2017-01-12 11:09:25 +08:00
# CHECK-NEXT: ArgIndices: [ ]
Add type records to TPI stream. I don't think the data I add to a TPI stream in this patch is correct, but at least it can be displayed using llvm-pdbdump. Until I add more streams to a PDB file, I'm not able to know whether the data will be accepted by MSVC tools or not. llvm-svn: 289183
2016-12-09 12:46:54 +08:00
# CHECK-NEXT: - Kind: LF_PROCEDURE
# CHECK-NEXT: Procedure:
# CHECK-NEXT: ReturnType: 116
# CHECK-NEXT: CallConv: NearC
# CHECK-NEXT: Options: [ None ]
# CHECK-NEXT: ParameterCount: 0
# CHECK-NEXT: ArgumentList: 4096
PDB: Merge type info. This patch is to merge type info in multiple .debug$T sections. One mystery that needs to be solved is that it is not clear how the MSVC linker uses TPI and IPI streams. Both streams contain type info, and it is not obvious what kind of record should go which. dumppdb command in microsoft-pdb repository prints out IPI stream contents as "IDs" and TPI stream as "TYPES", but looks like the tool don't really care about which stream type recrods were read from. For now, in this patch, I emit all type records to TPI stream. It might just work with other tools. If not, we need to investigate it more. llvm-svn: 291739
2017-01-12 11:09:25 +08:00
# CHECK-NEXT: - Kind: LF_POINTER
# CHECK-NEXT: Pointer:
# CHECK-NEXT: ReferentType: 4097
# CHECK-NEXT: Attrs: 65548
# CHECK-NEXT: - Kind: LF_ARGLIST
# CHECK-NEXT: ArgList:
# CHECK-NEXT: ArgIndices: [ 0 ]
# CHECK-NEXT: - Kind: LF_PROCEDURE
# CHECK-NEXT: Procedure:
# CHECK-NEXT: ReturnType: 116
# CHECK-NEXT: CallConv: NearC
# CHECK-NEXT: Options: [ None ]
# CHECK-NEXT: ParameterCount: 0
# CHECK-NEXT: ArgumentList: 4099
[PDB] Split item and type records when merging type streams Summary: MSVC does this when producing a PDB. Reviewers: ruiu Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31316 llvm-svn: 298717
2017-03-25 01:26:38 +08:00
# CHECK-NEXT: IpiStream:
# CHECK-NEXT: Version: VC80
# CHECK-NEXT: Records:
Add type records to TPI stream. I don't think the data I add to a TPI stream in this patch is correct, but at least it can be displayed using llvm-pdbdump. Until I add more streams to a PDB file, I'm not able to know whether the data will be accepted by MSVC tools or not. llvm-svn: 289183
2016-12-09 12:46:54 +08:00
# CHECK-NEXT: - Kind: LF_FUNC_ID
# CHECK-NEXT: FuncId:
# CHECK-NEXT: ParentScope: 0
PDB: Merge type info. This patch is to merge type info in multiple .debug$T sections. One mystery that needs to be solved is that it is not clear how the MSVC linker uses TPI and IPI streams. Both streams contain type info, and it is not obvious what kind of record should go which. dumppdb command in microsoft-pdb repository prints out IPI stream contents as "IDs" and TPI stream as "TYPES", but looks like the tool don't really care about which stream type recrods were read from. For now, in this patch, I emit all type records to TPI stream. It might just work with other tools. If not, we need to investigate it more. llvm-svn: 291739
2017-01-12 11:09:25 +08:00
# CHECK-NEXT: FunctionType: 4100
Add type records to TPI stream. I don't think the data I add to a TPI stream in this patch is correct, but at least it can be displayed using llvm-pdbdump. Until I add more streams to a PDB file, I'm not able to know whether the data will be accepted by MSVC tools or not. llvm-svn: 289183
2016-12-09 12:46:54 +08:00
# CHECK-NEXT: Name: main
PDB: Merge type info. This patch is to merge type info in multiple .debug$T sections. One mystery that needs to be solved is that it is not clear how the MSVC linker uses TPI and IPI streams. Both streams contain type info, and it is not obvious what kind of record should go which. dumppdb command in microsoft-pdb repository prints out IPI stream contents as "IDs" and TPI stream as "TYPES", but looks like the tool don't really care about which stream type recrods were read from. For now, in this patch, I emit all type records to TPI stream. It might just work with other tools. If not, we need to investigate it more. llvm-svn: 291739
2017-01-12 11:09:25 +08:00
# CHECK-NEXT: - Kind: LF_FUNC_ID
# CHECK-NEXT: FuncId:
# CHECK-NEXT: ParentScope: 0
# CHECK-NEXT: FunctionType: 4097
# CHECK-NEXT: Name: foo
Add type records to TPI stream. I don't think the data I add to a TPI stream in this patch is correct, but at least it can be displayed using llvm-pdbdump. Until I add more streams to a PDB file, I'm not able to know whether the data will be accepted by MSVC tools or not. llvm-svn: 289183
2016-12-09 12:46:54 +08:00
# CHECK-NEXT: - Kind: LF_STRING_ID
# CHECK-NEXT: StringId:
# CHECK-NEXT: Id: 0
# CHECK-NEXT: String: 'D:\b'
# CHECK-NEXT: - Kind: LF_STRING_ID
# CHECK-NEXT: StringId:
# CHECK-NEXT: Id: 0
# CHECK-NEXT: String: 'C:\vs14\VC\BIN\amd64\cl.exe'
# CHECK-NEXT: - Kind: LF_STRING_ID
# CHECK-NEXT: StringId:
# CHECK-NEXT: Id: 0
# CHECK-NEXT: String: '-Z7 -c -MT -IC:\vs14\VC\INCLUDE -IC:\vs14\VC\ATLMFC\INCLUDE -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.10150.0\ucrt" -I"C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6\include\um" -I"C:\Program Files (x86)\Windows Kits\8.1\include\shared"'
# CHECK-NEXT: - Kind: LF_SUBSTR_LIST
Update LLD tests for codeview dumping changes llvm-svn: 298475
2017-03-22 09:43:49 +08:00
# CHECK-NEXT: StringList:
[PDB] Split item and type records when merging type streams Summary: MSVC does this when producing a PDB. Reviewers: ruiu Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31316 llvm-svn: 298717
2017-03-25 01:26:38 +08:00
# CHECK-NEXT: StringIndices: [ 4100 ]
Add type records to TPI stream. I don't think the data I add to a TPI stream in this patch is correct, but at least it can be displayed using llvm-pdbdump. Until I add more streams to a PDB file, I'm not able to know whether the data will be accepted by MSVC tools or not. llvm-svn: 289183
2016-12-09 12:46:54 +08:00
# CHECK-NEXT: - Kind: LF_STRING_ID
# CHECK-NEXT: StringId:
[PDB] Split item and type records when merging type streams Summary: MSVC does this when producing a PDB. Reviewers: ruiu Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31316 llvm-svn: 298717
2017-03-25 01:26:38 +08:00
# CHECK-NEXT: Id: 4101
Add type records to TPI stream. I don't think the data I add to a TPI stream in this patch is correct, but at least it can be displayed using llvm-pdbdump. Until I add more streams to a PDB file, I'm not able to know whether the data will be accepted by MSVC tools or not. llvm-svn: 289183
2016-12-09 12:46:54 +08:00
# CHECK-NEXT: String: ' -I"C:\Program Files (x86)\Windows Kits\8.1\include\um" -I"C:\Program Files (x86)\Windows Kits\8.1\include\winrt" -TC -X'
# CHECK-NEXT: - Kind: LF_STRING_ID
# CHECK-NEXT: StringId:
# CHECK-NEXT: Id: 0
PDB: Merge type info. This patch is to merge type info in multiple .debug$T sections. One mystery that needs to be solved is that it is not clear how the MSVC linker uses TPI and IPI streams. Both streams contain type info, and it is not obvious what kind of record should go which. dumppdb command in microsoft-pdb repository prints out IPI stream contents as "IDs" and TPI stream as "TYPES", but looks like the tool don't really care about which stream type recrods were read from. For now, in this patch, I emit all type records to TPI stream. It might just work with other tools. If not, we need to investigate it more. llvm-svn: 291739
2017-01-12 11:09:25 +08:00
# CHECK-NEXT: String: ret42-main.c
Add type records to TPI stream. I don't think the data I add to a TPI stream in this patch is correct, but at least it can be displayed using llvm-pdbdump. Until I add more streams to a PDB file, I'm not able to know whether the data will be accepted by MSVC tools or not. llvm-svn: 289183
2016-12-09 12:46:54 +08:00
# CHECK-NEXT: - Kind: LF_STRING_ID
# CHECK-NEXT: StringId:
# CHECK-NEXT: Id: 0
# CHECK-NEXT: String: 'D:\b\vc140.pdb'
# CHECK-NEXT: - Kind: LF_BUILDINFO
# CHECK-NEXT: BuildInfo:
[PDB] Split item and type records when merging type streams Summary: MSVC does this when producing a PDB. Reviewers: ruiu Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31316 llvm-svn: 298717
2017-03-25 01:26:38 +08:00
# CHECK-NEXT: ArgIndices: [ 4098, 4099, 4103, 4104, 4102 ]
PDB: Merge type info. This patch is to merge type info in multiple .debug$T sections. One mystery that needs to be solved is that it is not clear how the MSVC linker uses TPI and IPI streams. Both streams contain type info, and it is not obvious what kind of record should go which. dumppdb command in microsoft-pdb repository prints out IPI stream contents as "IDs" and TPI stream as "TYPES", but looks like the tool don't really care about which stream type recrods were read from. For now, in this patch, I emit all type records to TPI stream. It might just work with other tools. If not, we need to investigate it more. llvm-svn: 291739
2017-01-12 11:09:25 +08:00
# CHECK-NEXT: - Kind: LF_STRING_ID
# CHECK-NEXT: StringId:
# CHECK-NEXT: Id: 0
# CHECK-NEXT: String: ret42-sub.c
# CHECK-NEXT: - Kind: LF_BUILDINFO
# CHECK-NEXT: BuildInfo:
[PDB] Split item and type records when merging type streams Summary: MSVC does this when producing a PDB. Reviewers: ruiu Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31316 llvm-svn: 298717
2017-03-25 01:26:38 +08:00
# CHECK-NEXT: ArgIndices: [ 4098, 4099, 4106, 4104, 4102 ]
Check /pdb output using llvm-pdbdump. test/COFF/rsds.test checks only RSDS directory in a DLL and didn't check the validity of the PDF file produced. (Technically the produced PDB is not valid because it is really a stub, but this test is still good to have.) llvm-svn: 281678
2016-09-16 07:14:40 +08:00
Resubmit "[llvm-pdbutil] rewrite the "raw" output style." This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
2017-06-16 06:24:24 +08:00
RAW: Modules
RAW-NEXT: ============================================================
[llvm-pdbutil] Add support for dumping detailed module stats. This adds support for dumping a summary of module symbols and CodeView debug chunks. This option prints a table for each module of all of the symbols that occurred in the module and the number of times it occurred and total byte size. Then at the end it prints the totals for the entire file. Additionally, this patch adds the -jmc (just my code) option, which suppresses modules which are from external libraries or linker imports, so that you can focus only on the object files and libraries that originate from your own source code. llvm-svn: 311338
2017-08-21 22:53:25 +08:00
RAW-NEXT: Mod 0000 | `{{.*}}pdb.test.tmp1.obj`:
[LLD/PDB] Emit first section contribution for DBI Module Descriptor. Part of the DBI stream is a list of variable length structures describing each module that contributes to the final executable. One member of this structure is a section contribution entry that describes the first section contribution in the output file for the given module. We have been leaving this structure unpopulated until now, so with this patch it is now filled out correctly. Differential Revision: https://reviews.llvm.org/D45832 llvm-svn: 330457
2018-04-21 02:00:46 +08:00
RAW-NEXT: SC[.text] | mod = 0, 0001:0000, size = 14, data crc = 1682752513, reloc crc = 0
RAW-NEXT: IMAGE_SCN_CNT_CODE | IMAGE_SCN_ALIGN_16BYTES | IMAGE_SCN_MEM_EXECUTE |
RAW-NEXT: IMAGE_SCN_MEM_READ
Fix pdb embedded paths. Obviously the paths are going to be machine dependent, so don't try to match them in the test. llvm-svn: 305518
2017-06-16 06:30:00 +08:00
RAW-NEXT: Obj: `{{.*}}pdb.test.tmp1.obj`:
[PDB] Make our PDBs look more like MS PDBs. When investigating bugs in PDB generation, the first step is often to do the same link with link.exe and then compare PDBs. But comparing PDBs is hard because two completely different byte sequences can both be correct, so it hampers the investigation when you also have to spend time figuring out not just which bytes are different, but also if the difference is meaningful. This patch fixes a couple of cases related to string table emission, hash table emission, and the order in which we emit strings that makes more of our bytes the same as the bytes generated by MS PDBs. Differential Revision: https://reviews.llvm.org/D44810 llvm-svn: 328348
2018-03-24 02:43:39 +08:00
RAW-NEXT: debug stream: 11, # files: 1, has ec info: false
Fix lld tests after r307356. llvm-svn: 307360
2017-07-07 13:41:25 +08:00
RAW-NEXT: pdb file ni: 0 ``, src file ni: 0 ``
[llvm-pdbutil] Add support for dumping detailed module stats. This adds support for dumping a summary of module symbols and CodeView debug chunks. This option prints a table for each module of all of the symbols that occurred in the module and the number of times it occurred and total byte size. Then at the end it prints the totals for the entire file. Additionally, this patch adds the -jmc (just my code) option, which suppresses modules which are from external libraries or linker imports, so that you can focus only on the object files and libraries that originate from your own source code. llvm-svn: 311338
2017-08-21 22:53:25 +08:00
RAW-NEXT: Mod 0001 | `{{.*}}pdb.test.tmp2.obj`:
[LLD/PDB] Emit first section contribution for DBI Module Descriptor. Part of the DBI stream is a list of variable length structures describing each module that contributes to the final executable. One member of this structure is a section contribution entry that describes the first section contribution in the output file for the given module. We have been leaving this structure unpopulated until now, so with this patch it is now filled out correctly. Differential Revision: https://reviews.llvm.org/D45832 llvm-svn: 330457
2018-04-21 02:00:46 +08:00
RAW-NEXT: SC[.text] | mod = 1, 0001:0016, size = 6, data crc = 2139436471, reloc crc = 0
RAW-NEXT: IMAGE_SCN_CNT_CODE | IMAGE_SCN_ALIGN_16BYTES | IMAGE_SCN_MEM_EXECUTE |
RAW-NEXT: IMAGE_SCN_MEM_READ
Fix pdb embedded paths. Obviously the paths are going to be machine dependent, so don't try to match them in the test. llvm-svn: 305518
2017-06-16 06:30:00 +08:00
RAW-NEXT: Obj: `{{.*}}pdb.test.tmp2.obj`:
[PDB] Make our PDBs look more like MS PDBs. When investigating bugs in PDB generation, the first step is often to do the same link with link.exe and then compare PDBs. But comparing PDBs is hard because two completely different byte sequences can both be correct, so it hampers the investigation when you also have to spend time figuring out not just which bytes are different, but also if the difference is meaningful. This patch fixes a couple of cases related to string table emission, hash table emission, and the order in which we emit strings that makes more of our bytes the same as the bytes generated by MS PDBs. Differential Revision: https://reviews.llvm.org/D44810 llvm-svn: 328348
2018-03-24 02:43:39 +08:00
RAW-NEXT: debug stream: 12, # files: 1, has ec info: false
Fix lld tests after r307356. llvm-svn: 307360
2017-07-07 13:41:25 +08:00
RAW-NEXT: pdb file ni: 0 ``, src file ni: 0 ``
[llvm-pdbutil] Add support for dumping detailed module stats. This adds support for dumping a summary of module symbols and CodeView debug chunks. This option prints a table for each module of all of the symbols that occurred in the module and the number of times it occurred and total byte size. Then at the end it prints the totals for the entire file. Additionally, this patch adds the -jmc (just my code) option, which suppresses modules which are from external libraries or linker imports, so that you can focus only on the object files and libraries that originate from your own source code. llvm-svn: 311338
2017-08-21 22:53:25 +08:00
RAW-NEXT: Mod 0002 | `* Linker *`:
[llvm-pdbutil] Dump first section contribution for each module. The DBI stream contains a list of module descriptors. At the beginning of each descriptor is a structure representing the first section contribution in the output file for that module. LLD currently doesn't fill out this structure at all, but link.exe does. So as a precursor to emitting this data in LLD, we first need a way to dump it so that it can be checked. This patch adds support for the dumping, and verifies via a test that LLD emits bogus information. llvm-svn: 330208
2018-04-18 04:06:43 +08:00
RAW-NEXT: SC[???] | mod = 2, 0000:0000, size = 0, data crc = 0, reloc crc = 0
RAW-NEXT: none
Resubmit "[llvm-pdbutil] rewrite the "raw" output style." This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
2017-06-16 06:24:24 +08:00
RAW-NEXT: Obj: ``:
[PDB] Make our PDBs look more like MS PDBs. When investigating bugs in PDB generation, the first step is often to do the same link with link.exe and then compare PDBs. But comparing PDBs is hard because two completely different byte sequences can both be correct, so it hampers the investigation when you also have to spend time figuring out not just which bytes are different, but also if the difference is meaningful. This patch fixes a couple of cases related to string table emission, hash table emission, and the order in which we emit strings that makes more of our bytes the same as the bytes generated by MS PDBs. Differential Revision: https://reviews.llvm.org/D44810 llvm-svn: 328348
2018-03-24 02:43:39 +08:00
RAW-NEXT: debug stream: 13, # files: 0, has ec info: false
Fix lld tests after r307356. llvm-svn: 307360
2017-07-07 13:41:25 +08:00
RAW-NEXT: pdb file ni: 1 `{{.*pdb.test.tmp.pdb}}`, src file ni: 0 ``
Resubmit "[llvm-pdbutil] rewrite the "raw" output style." This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
2017-06-16 06:24:24 +08:00
RAW: Types (TPI Stream)
RAW-NEXT: ============================================================
RAW-NEXT: Showing 5 records
[PDB] Emit TPI and IPI hashes llvm-svn: 308497
2017-07-20 01:26:07 +08:00
RAW-NEXT: 0x1000 | LF_ARGLIST [size = 8, hash = 0xEC0]
RAW-NEXT: 0x1001 | LF_PROCEDURE [size = 16, hash = 0x7BC]
Resubmit "[llvm-pdbutil] rewrite the "raw" output style." This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
2017-06-16 06:24:24 +08:00
RAW-NEXT: return type = 0x0074 (int), # args = 0, param list = 0x1000
RAW-NEXT: calling conv = cdecl, options = None
[PDB] Emit TPI and IPI hashes llvm-svn: 308497
2017-07-20 01:26:07 +08:00
RAW-NEXT: 0x1002 | LF_POINTER [size = 12, hash = 0x884]
Resubmit "[llvm-pdbutil] rewrite the "raw" output style." This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
2017-06-16 06:24:24 +08:00
RAW-NEXT: referent = 0x1001, mode = pointer, opts = None, kind = ptr64
[PDB] Emit TPI and IPI hashes llvm-svn: 308497
2017-07-20 01:26:07 +08:00
RAW-NEXT: 0x1003 | LF_ARGLIST [size = 12, hash = 0x936]
Resubmit "[llvm-pdbutil] rewrite the "raw" output style." This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
2017-06-16 06:24:24 +08:00
RAW-NEXT: <no type>: ``
[PDB] Emit TPI and IPI hashes llvm-svn: 308497
2017-07-20 01:26:07 +08:00
RAW-NEXT: 0x1004 | LF_PROCEDURE [size = 16, hash = 0x852]
Resubmit "[llvm-pdbutil] rewrite the "raw" output style." This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
2017-06-16 06:24:24 +08:00
RAW-NEXT: return type = 0x0074 (int), # args = 0, param list = 0x1003
RAW-NEXT: calling conv = cdecl, options = None
RAW: Types (IPI Stream)
RAW-NEXT: ============================================================
RAW-NEXT: Showing 12 records
[PDB] Emit TPI and IPI hashes llvm-svn: 308497
2017-07-20 01:26:07 +08:00
RAW-NEXT: 0x1000 | LF_FUNC_ID [size = 20, hash = 0x330]
Resubmit "[llvm-pdbutil] rewrite the "raw" output style." This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
2017-06-16 06:24:24 +08:00
RAW-NEXT: name = main, type = 0x1004, parent scope = <no type>
[PDB] Emit TPI and IPI hashes llvm-svn: 308497
2017-07-20 01:26:07 +08:00
RAW-NEXT: 0x1001 | LF_FUNC_ID [size = 16, hash = 0x120]
Resubmit "[llvm-pdbutil] rewrite the "raw" output style." This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
2017-06-16 06:24:24 +08:00
RAW-NEXT: name = foo, type = 0x1001, parent scope = <no type>
[PDB] Emit TPI and IPI hashes llvm-svn: 308497
2017-07-20 01:26:07 +08:00
RAW-NEXT: 0x1002 | LF_STRING_ID [size = 16, hash = 0x757] ID: <no type>, String: D:\b
RAW-NEXT: 0x1003 | LF_STRING_ID [size = 36, hash = 0xC3A] ID: <no type>, String: C:\vs14\VC\BIN\amd64\cl.exe
RAW-NEXT: 0x1004 | LF_STRING_ID [size = 260, hash = 0x433] ID: <no type>, String: -Z7 -c -MT -IC:\vs14\VC\INCLUDE -IC:\vs14\VC\ATLMFC\INCLUDE -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.10150.0\ucrt" -I"C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6\include\um" -I"C:\Program Files (x86)\Windows Kits\8.1\include\shared"
RAW-NEXT: 0x1005 | LF_SUBSTR_LIST [size = 12, hash = 0x759]
Resubmit "[llvm-pdbutil] rewrite the "raw" output style." This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
2017-06-16 06:24:24 +08:00
RAW-NEXT: 0x1004: `-Z7 -c -MT -IC:\vs14\VC\INCLUDE -IC:\vs14\VC\ATLMFC\INCLUDE -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.10150.0\ucrt" -I"C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6\include\um" -I"C:\Program Files (x86)\Windows Kits\8.1\include\shared"`
[PDB] Emit TPI and IPI hashes llvm-svn: 308497
2017-07-20 01:26:07 +08:00
RAW-NEXT: 0x1006 | LF_STRING_ID [size = 132, hash = 0xF57] ID: 0x1005, String: -I"C:\Program Files (x86)\Windows Kits\8.1\include\um" -I"C:\Program Files (x86)\Windows Kits\8.1\include\winrt" -TC -X
RAW-NEXT: 0x1007 | LF_STRING_ID [size = 24, hash = 0x2D1] ID: <no type>, String: ret42-main.c
RAW-NEXT: 0x1008 | LF_STRING_ID [size = 24, hash = 0xB8B] ID: <no type>, String: D:\b\vc140.pdb
RAW-NEXT: 0x1009 | LF_BUILDINFO [size = 28, hash = 0xA8C]
Resubmit "[llvm-pdbutil] rewrite the "raw" output style." This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
2017-06-16 06:24:24 +08:00
RAW-NEXT: 0x1002: `D:\b`
RAW-NEXT: 0x1003: `C:\vs14\VC\BIN\amd64\cl.exe`
RAW-NEXT: 0x1007: `ret42-main.c`
RAW-NEXT: 0x1008: `D:\b\vc140.pdb`
RAW-NEXT: 0x1006: ` -I"C:\Program Files (x86)\Windows Kits\8.1\include\um" -I"C:\Program Files (x86)\Windows Kits\8.1\include\winrt" -TC -X`
[PDB] Emit TPI and IPI hashes llvm-svn: 308497
2017-07-20 01:26:07 +08:00
RAW-NEXT: 0x100A | LF_STRING_ID [size = 20, hash = 0x39C] ID: <no type>, String: ret42-sub.c
RAW-NEXT: 0x100B | LF_BUILDINFO [size = 28, hash = 0xAD7]
Resubmit "[llvm-pdbutil] rewrite the "raw" output style." This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
2017-06-16 06:24:24 +08:00
RAW-NEXT: 0x1002: `D:\b`
RAW-NEXT: 0x1003: `C:\vs14\VC\BIN\amd64\cl.exe`
RAW-NEXT: 0x100A: `ret42-sub.c`
RAW-NEXT: 0x1008: `D:\b\vc140.pdb`
RAW-NEXT: 0x1006: ` -I"C:\Program Files (x86)\Windows Kits\8.1\include\um" -I"C:\Program Files (x86)\Windows Kits\8.1\include\winrt" -TC -X`
[PDB] Write public symbol records and the publics hash table Summary: MSVC link.exe records all external symbol names in the publics stream. It provides similar functionality to an ELF .symtab. Reviewers: zturner, ruiu Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D35871 llvm-svn: 309303
2017-07-28 02:25:59 +08:00
RAW: Public Symbols
[PDB] Fix an issue writing the publics stream. In the refactor to merge the publics and globals stream, a bug was introduced that wrote the wrong value for one of the fields of the PublicsStreamHeader. This caused debugging in WinDbg to break. We had no way of dumping any of these fields, so in addition to fixing the bug I've added dumping support for them along with a test that verifies the correct value is written. llvm-svn: 310439
2017-08-09 12:23:59 +08:00
RAW-NEXT: ============================================================
RAW-NEXT: Publics Header
RAW-NEXT: sym hash = 556, thunk table addr = 0000:0000
RAW-NEXT: GSI Header
RAW-NEXT: sig = 0xFFFFFFFF, hdr = 0xF12F091A, hr size = 16, num buckets = 524
RAW-NEXT: Records
RAW-NEXT: 20 | S_PUB32 [size = 20] `main`
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
RAW-NEXT: flags = function, addr = 0001:0000
[PDB] Fix an issue writing the publics stream. In the refactor to merge the publics and globals stream, a bug was introduced that wrote the wrong value for one of the fields of the PublicsStreamHeader. This caused debugging in WinDbg to break. We had no way of dumping any of these fields, so in addition to fixing the bug I've added dumping support for them along with a test that verifies the correct value is written. llvm-svn: 310439
2017-08-09 12:23:59 +08:00
RAW-NEXT: 0 | S_PUB32 [size = 20] `foo`
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
RAW-NEXT: flags = function, addr = 0001:0016
[PDB] Fix an issue writing the publics stream. In the refactor to merge the publics and globals stream, a bug was introduced that wrote the wrong value for one of the fields of the PublicsStreamHeader. This caused debugging in WinDbg to break. We had no way of dumping any of these fields, so in addition to fixing the bug I've added dumping support for them along with a test that verifies the correct value is written. llvm-svn: 310439
2017-08-09 12:23:59 +08:00
RAW-NOT: S_PUB32
RAW-NEXT: Hash Entries
RAW-NEXT: off = 21, refcnt = 1
RAW-NEXT: off = 1, refcnt = 1
RAW-NEXT: Hash Buckets
RAW-NEXT: 0x00000000
RAW-NEXT: 0x0000000c
RAW-NEXT: Address Map
RAW-NEXT: off = 20
RAW-NEXT: off = 0
[llvm-pdbutil] Dump image section headers. Image section headers are stored in the DBI stream, but we had no way to dump them. This patch adds dumping support, along with some tests that LLD actually dumps them correctly. Differential Revision: https://reviews.llvm.org/D36332 llvm-svn: 310107
2017-08-05 04:02:38 +08:00
RAW: Section Headers
RAW-NEXT: ============================================================
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
[llvm-pdbutil] Dump image section headers. Image section headers are stored in the DBI stream, but we had no way to dump them. This patch adds dumping support, along with some tests that LLD actually dumps them correctly. Differential Revision: https://reviews.llvm.org/D36332 llvm-svn: 310107
2017-08-05 04:02:38 +08:00
RAW: SECTION HEADER #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
RAW-NEXT: .text name
RAW-NEXT: 16 virtual size
RAW-NEXT: 1000 virtual address
RAW-NEXT: 200 size of raw data
RAW-NEXT: 400 file pointer to raw data
RAW-NEXT: 0 file pointer to relocation table
RAW-NEXT: 0 file pointer to line numbers
RAW-NEXT: 0 number of relocations
RAW-NEXT: 0 number of line numbers
RAW-NEXT: 60000020 flags
RAW-NEXT: IMAGE_SCN_CNT_CODE
RAW-NEXT: IMAGE_SCN_MEM_EXECUTE
RAW-NEXT: IMAGE_SCN_MEM_READ
[llvm-pdbutil] Dump image section headers. Image section headers are stored in the DBI stream, but we had no way to dump them. This patch adds dumping support, along with some tests that LLD actually dumps them correctly. Differential Revision: https://reviews.llvm.org/D36332 llvm-svn: 310107
2017-08-05 04:02:38 +08:00
RAW: SECTION HEADER #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
RAW-NEXT: .rdata name
Fix test after r329221 It seems I accidentally overspecified the section size in my previous commit, whereas it was previously carefully left out. llvm-svn: 329222
2018-04-05 03:36:27 +08:00
RAW-NEXT: virtual size
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
RAW-NEXT: 2000 virtual address
RAW-NEXT: 200 size of raw data
RAW-NEXT: 600 file pointer to raw data
RAW-NEXT: 0 file pointer to relocation table
RAW-NEXT: 0 file pointer to line numbers
RAW-NEXT: 0 number of relocations
RAW-NEXT: 0 number of line numbers
RAW-NEXT: 40000040 flags
RAW-NEXT: IMAGE_SCN_CNT_INITIALIZED_DATA
RAW-NEXT: IMAGE_SCN_MEM_READ
[llvm-pdbutil] Dump image section headers. Image section headers are stored in the DBI stream, but we had no way to dump them. This patch adds dumping support, along with some tests that LLD actually dumps them correctly. Differential Revision: https://reviews.llvm.org/D36332 llvm-svn: 310107
2017-08-05 04:02:38 +08:00
RAW: SECTION HEADER #3
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
RAW-NEXT: .pdata name
RAW-NEXT: C virtual size
RAW-NEXT: 3000 virtual address
RAW-NEXT: 200 size of raw data
RAW-NEXT: 800 file pointer to raw data
RAW-NEXT: 0 file pointer to relocation table
RAW-NEXT: 0 file pointer to line numbers
RAW-NEXT: 0 number of relocations
RAW-NEXT: 0 number of line numbers
RAW-NEXT: 40000040 flags
RAW-NEXT: IMAGE_SCN_CNT_INITIALIZED_DATA
RAW-NEXT: IMAGE_SCN_MEM_READ
[llvm-pdbutil] Dump image section headers. Image section headers are stored in the DBI stream, but we had no way to dump them. This patch adds dumping support, along with some tests that LLD actually dumps them correctly. Differential Revision: https://reviews.llvm.org/D36332 llvm-svn: 310107
2017-08-05 04:02:38 +08:00
RAW: Original Section Headers
RAW-NEXT: ============================================================
RAW-NEXT: PDB does not contain the requested image section header type
Resubmit "[llvm-pdbutil] rewrite the "raw" output style." This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
2017-06-16 06:24:24 +08:00
RAW: Section Contributions
RAW-NEXT: ============================================================
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
RAW-NEXT: SC[.text] | mod = 0, 0001:0000, size = 14, data crc = 1682752513, reloc crc = 0
More PDB buildbot fixes. llvm-svn: 310131
2017-08-05 05:18:17 +08:00
RAW-NEXT: IMAGE_SCN_CNT_CODE | IMAGE_SCN_ALIGN_16BYTES | IMAGE_SCN_MEM_EXECUTE |
RAW-NEXT: IMAGE_SCN_MEM_READ
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
RAW-NEXT: SC[.text] | mod = 1, 0001:0016, size = 6, data crc = 2139436471, reloc crc = 0
More PDB buildbot fixes. llvm-svn: 310131
2017-08-05 05:18:17 +08:00
RAW-NEXT: IMAGE_SCN_CNT_CODE | IMAGE_SCN_ALIGN_16BYTES | IMAGE_SCN_MEM_EXECUTE |
RAW-NEXT: IMAGE_SCN_MEM_READ
Fix the test some more after r329221 llvm-svn: 329224
2018-04-05 03:55:45 +08:00
RAW-NEXT: SC[.rdata] | mod = 2, 0002:0000, size = {{[0-9]+}}, data crc = 0, reloc crc = 0
Merge .xdata into .rdata by default Summary: MSVC does this. The user can override it with their own /merge: flag. Reviewers: ruiu, pcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40197 llvm-svn: 318699
2017-11-21 05:49:35 +08:00
RAW-NEXT: IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ
Fix the test some more after r329221 llvm-svn: 329224
2018-04-05 03:55:45 +08:00
RAW-NEXT: SC[.rdata] | mod = 2, 0002:0028, size = {{[0-9]+}}, data crc = 0, reloc crc = 0
Merge .xdata into .rdata by default Summary: MSVC does this. The user can override it with their own /merge: flag. Reviewers: ruiu, pcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40197 llvm-svn: 318699
2017-11-21 05:49:35 +08:00
RAW-NEXT: IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ
COFF: Merge .xdata into .rdata by default. Differential Revision: https://reviews.llvm.org/D45804 llvm-svn: 330484
2018-04-21 05:32:37 +08:00
RAW-NEXT: SC[.rdata] | mod = 0, 0002:0148, size = {{[0-9]+}}, data crc = 264583633, reloc crc = 0
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
RAW-NEXT: IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_ALIGN_4BYTES | IMAGE_SCN_MEM_READ
COFF: Merge .xdata into .rdata by default. Differential Revision: https://reviews.llvm.org/D45804 llvm-svn: 330484
2018-04-21 05:32:37 +08:00
RAW-NEXT: SC[.pdata] | mod = 0, 0003:0000, size = 12, data crc = 361370162, reloc crc = 0
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
RAW-NEXT: IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_ALIGN_4BYTES | IMAGE_SCN_MEM_READ
Merge .xdata into .rdata by default Summary: MSVC does this. The user can override it with their own /merge: flag. Reviewers: ruiu, pcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40197 llvm-svn: 318699
2017-11-21 05:49:35 +08:00
RAW-NOT: SC[
Resubmit "[llvm-pdbutil] rewrite the "raw" output style." This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
2017-06-16 06:24:24 +08:00
RAW: Section Map
RAW-NEXT: ============================================================
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
[llvm-pdbutil] Dump image section headers. Image section headers are stored in the DBI stream, but we had no way to dump them. This patch adds dumping support, along with some tests that LLD actually dumps them correctly. Differential Revision: https://reviews.llvm.org/D36332 llvm-svn: 310107
2017-08-05 04:02:38 +08:00
RAW-NEXT: Section 0000 | ovl = 0, group = 0, frame = 1, name = 65535
Fix the test some more after r329221 llvm-svn: 329224
2018-04-05 03:55:45 +08:00
RAW-NEXT: class = 65535, offset = 0, size =
Resubmit "[llvm-pdbutil] rewrite the "raw" output style." This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
2017-06-16 06:24:24 +08:00
RAW-NEXT: flags = read | execute | 32 bit addr | selector
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
RAW-NEXT: Section 0001 | ovl = 0, group = 0, frame = 2, name = 65535
Fix the test some more after r329221 llvm-svn: 329224
2018-04-05 03:55:45 +08:00
RAW-NEXT: class = 65535, offset = 0, size =
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
RAW-NEXT: flags = read | 32 bit addr | selector
[llvm-pdbutil] Dump image section headers. Image section headers are stored in the DBI stream, but we had no way to dump them. This patch adds dumping support, along with some tests that LLD actually dumps them correctly. Differential Revision: https://reviews.llvm.org/D36332 llvm-svn: 310107
2017-08-05 04:02:38 +08:00
RAW-NEXT: Section 0002 | ovl = 0, group = 0, frame = 3, name = 65535
Fix the test some more after r329221 llvm-svn: 329224
2018-04-05 03:55:45 +08:00
RAW-NEXT: class = 65535, offset = 0, size =
Resubmit "[llvm-pdbutil] rewrite the "raw" output style." This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
2017-06-16 06:24:24 +08:00
RAW-NEXT: flags = read | 32 bit addr | selector
[llvm-pdbutil] Dump image section headers. Image section headers are stored in the DBI stream, but we had no way to dump them. This patch adds dumping support, along with some tests that LLD actually dumps them correctly. Differential Revision: https://reviews.llvm.org/D36332 llvm-svn: 310107
2017-08-05 04:02:38 +08:00
RAW-NEXT: Section 0003 | ovl = 0, group = 0, frame = 4, name = 65535
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
RAW-NEXT: class = 65535, offset = 0, size = 4294967295
Resubmit "[llvm-pdbutil] rewrite the "raw" output style." This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
2017-06-16 06:24:24 +08:00
RAW-NEXT: flags = 32 bit addr | absolute addr