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

203 lines
11 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
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] Rename "raw" to "dump". Now you run llvm-pdbutil dump <options>. This is a followup after having renamed the tool, whereas before raw was obviously just the style of dumping, whereas now "dump" is the action to perform with the "util". llvm-svn: 306055
2017-06-23 04:57:39 +08:00
# RUN: llvm-pdbutil dump -modules -section-map -section-contribs \
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
# RUN: -types -ids %t.pdb | 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
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: FreeBlockMap: 1
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:
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: Signature: 0
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:
# CHECK-NEXT: VerHeader: V110
# CHECK-NEXT: Age: 1
# CHECK-NEXT: BuildNumber: 0
# CHECK-NEXT: PdbDllVersion: 0
# CHECK-NEXT: PdbDllRbld: 0
# CHECK-NEXT: Flags: 0
# CHECK-NEXT: MachineType: x86
# 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: ============================================================
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: Mod 0000 | Name: `{{.*}}pdb.test.tmp1.obj`:
RAW-NEXT: Obj: `{{.*}}pdb.test.tmp1.obj`:
[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
RAW-NEXT: debug stream: 9, # 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 ``
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: Mod 0001 | Name: `{{.*}}pdb.test.tmp2.obj`:
RAW-NEXT: Obj: `{{.*}}pdb.test.tmp2.obj`:
[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
RAW-NEXT: debug stream: 10, # 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 ``
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: Mod 0002 | Name: `* Linker *`:
RAW-NEXT: Obj: ``:
RAW-NEXT: debug stream: 11, # 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
RAW-NEXT: 0x1000 | LF_ARGLIST [size = 8]
RAW-NEXT: 0x1001 | LF_PROCEDURE [size = 16]
RAW-NEXT: return type = 0x0074 (int), # args = 0, param list = 0x1000
RAW-NEXT: calling conv = cdecl, options = None
RAW-NEXT: 0x1002 | LF_POINTER [size = 12]
RAW-NEXT: referent = 0x1001, mode = pointer, opts = None, kind = ptr64
RAW-NEXT: 0x1003 | LF_ARGLIST [size = 12]
RAW-NEXT: <no type>: ``
RAW-NEXT: 0x1004 | LF_PROCEDURE [size = 16]
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
RAW-NEXT: 0x1000 | LF_FUNC_ID [size = 20]
RAW-NEXT: name = main, type = 0x1004, parent scope = <no type>
RAW-NEXT: 0x1001 | LF_FUNC_ID [size = 16]
RAW-NEXT: name = foo, type = 0x1001, parent scope = <no type>
RAW-NEXT: 0x1002 | LF_STRING_ID [size = 16] ID: <no type>, String: D:\b
RAW-NEXT: 0x1003 | LF_STRING_ID [size = 36] ID: <no type>, String: C:\vs14\VC\BIN\amd64\cl.exe
RAW-NEXT: 0x1004 | LF_STRING_ID [size = 260] 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]
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"`
RAW-NEXT: 0x1006 | LF_STRING_ID [size = 132] 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] ID: <no type>, String: ret42-main.c
RAW-NEXT: 0x1008 | LF_STRING_ID [size = 24] ID: <no type>, String: D:\b\vc140.pdb
RAW-NEXT: 0x1009 | LF_BUILDINFO [size = 28]
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`
RAW-NEXT: 0x100A | LF_STRING_ID [size = 20] ID: <no type>, String: ret42-sub.c
RAW-NEXT: 0x100B | LF_BUILDINFO [size = 28]
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`
RAW: Section Contributions
RAW-NEXT: ============================================================
RAW-NEXT: SC | mod = 0, 65535:1288, size = 14, data crc = 0, reloc crc = 0
RAW-NEXT: IMAGE_SCN_CNT_CODE | IMAGE_SCN_ALIGN_16BYTES | IMAGE_SCN_MEM_EXECUTE |
RAW-NEXT: IMAGE_SCN_MEM_READ
RAW-NEXT: SC | mod = 0, 65535:1312, size = 8, data crc = 0, reloc crc = 0
RAW-NEXT: IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_ALIGN_4BYTES | IMAGE_SCN_MEM_READ
RAW-NEXT: SC | mod = 0, 65535:1320, size = 12, data crc = 0, reloc crc = 0
RAW-NEXT: IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_ALIGN_4BYTES | IMAGE_SCN_MEM_READ
RAW-NEXT: SC | mod = 1, 65535:1144, size = 6, data crc = 0, reloc crc = 0
RAW-NEXT: IMAGE_SCN_CNT_CODE | IMAGE_SCN_ALIGN_16BYTES | IMAGE_SCN_MEM_EXECUTE |
RAW-NEXT: IMAGE_SCN_MEM_READ
RAW: Section Map
RAW-NEXT: ============================================================
RAW-NEXT: Section 0000 | ovl = 0, group = 0, frame = 0, name = 1
Remove some non-determinstic numbers from pdb test. llvm-svn: 305520
2017-06-16 06:41: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
RAW-NEXT: Section 0001 | ovl = 1, group = 0, frame = 0, name = 2
Remove some non-determinstic numbers from pdb test. llvm-svn: 305520
2017-06-16 06:41: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
RAW-NEXT: Section 0002 | ovl = 2, group = 0, frame = 0, name = 3
Remove some non-determinstic numbers from pdb test. llvm-svn: 305520
2017-06-16 06:41: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
RAW-NEXT: Section 0003 | ovl = 3, group = 0, frame = 0, name = 4
Remove some non-determinstic numbers from pdb test. llvm-svn: 305520
2017-06-16 06:41: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
RAW-NEXT: Section 0004 | ovl = 4, group = 0, frame = 0, name = 5
Remove some non-determinstic numbers from pdb test. llvm-svn: 305520
2017-06-16 06:41: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 = 32 bit addr | absolute addr