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

567 lines
20 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 \
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: /debugpdb %t1.obj %t2.obj
Partially fill Info stream with proper values. llvm-svn: 281795
2016-09-17 06:51:17 +08:00
# RUN: llvm-pdbdump 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
# 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:
# CHECK-NEXT: NumStreams:
# CHECK-NEXT: FileSize:
# CHECK-NEXT: StreamSizes:
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: 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
# 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
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
# 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: [ 4105 ]
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: 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: Id: 4106
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: 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: [ 4103, 4104, 4108, 4109, 4107 ]
# 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:
# CHECK-NEXT: ArgIndices: [ 4103, 4104, 4111, 4109, 4107 ]
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: IpiStream:
# CHECK-NEXT: Version: VC80
# CHECK-NEXT: Records:
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
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
# RAW: FileHeaders {
# RAW-NEXT: BlockSize: 4096
# RAW-NEXT: FreeBlockMap: 1
# RAW-NEXT: NumBlocks: 10
# RAW-NEXT: NumDirectoryBytes: 48
# RAW-NEXT: Unknown1: 0
# RAW-NEXT: BlockMapAddr: 3
# RAW-NEXT: NumDirectoryBlocks: 1
# RAW-NEXT: DirectoryBlocks: [9]
# RAW-NEXT: NumStreams: 6
# RAW-NEXT: }
# RAW-NEXT: Streams [
# RAW-NEXT: Stream 0: [Old MSF Directory] (0 bytes)
# RAW-NEXT: Stream 1: [PDB Stream] (48 bytes)
# RAW-NEXT: Stream 2: [TPI Stream] (736 bytes)
# RAW-NEXT: Stream 3: [DBI Stream] (390 bytes)
# RAW-NEXT: Stream 4: [IPI Stream] (56 bytes)
# RAW-NEXT: Stream 5: [Section Header Data] (160 bytes)
# RAW-NEXT: ]
# RAW-NEXT: Msf Free Pages: []
# RAW-NEXT: Orphaned Pages: []
# RAW-NEXT: Multiply Used Pages: []
# RAW-NEXT: Use After Free Pages: []
# RAW-NEXT: StreamBlocks [
# RAW-NEXT: Stream 0: []
# RAW-NEXT: Stream 1: [5]
# RAW-NEXT: Stream 2: [7]
# RAW-NEXT: Stream 3: [6]
# RAW-NEXT: Stream 4: [8]
# RAW-NEXT: Stream 5: [4]
# RAW-NEXT: ]
# RAW-NEXT: PDB Stream {
# RAW-NEXT: Version: 20000404
# RAW-NEXT: Signature: 0x0
# RAW-NEXT: Age: 1
# RAW-NEXT: Guid: {7EBCCC79-C488-0267-C898-06D7E94A8A10}
# RAW-NEXT: }
# RAW-NEXT: Type Info Stream (TPI) {
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
# RAW-NEXT: TPI Version: 20040203
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
# RAW-NEXT: Record count: 17
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
# RAW-NEXT: Records [
# RAW-NEXT: {
# RAW-NEXT: ArgList (0x1000) {
# RAW-NEXT: TypeLeafKind: LF_ARGLIST (0x1201)
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
# RAW-NEXT: NumArgs: 0
# RAW-NEXT: Arguments [
# RAW-NEXT: ]
# RAW-NEXT: }
# RAW-NEXT: }
# RAW-NEXT: {
# RAW-NEXT: Procedure (0x1001) {
# RAW-NEXT: TypeLeafKind: LF_PROCEDURE (0x1008)
# RAW-NEXT: ReturnType: int (0x74)
# RAW-NEXT: CallingConvention: NearC (0x0)
# RAW-NEXT: FunctionOptions [ (0x0)
# RAW-NEXT: ]
# RAW-NEXT: NumParameters: 0
# RAW-NEXT: ArgListType: () (0x1000)
# RAW-NEXT: }
# RAW-NEXT: }
# RAW-NEXT: {
# RAW-NEXT: Pointer (0x1002) {
# RAW-NEXT: TypeLeafKind: LF_POINTER (0x1002)
# RAW-NEXT: PointeeType: int () (0x1001)
# RAW-NEXT: PointerAttributes: 0x1000C
# RAW-NEXT: PtrType: Near64 (0xC)
# RAW-NEXT: PtrMode: Pointer (0x0)
# RAW-NEXT: IsFlat: 0
# RAW-NEXT: IsConst: 0
# RAW-NEXT: IsVolatile: 0
# RAW-NEXT: IsUnaligned: 0
# RAW-NEXT: SizeOf: 8
# RAW-NEXT: }
# RAW-NEXT: }
# RAW-NEXT: {
# RAW-NEXT: ArgList (0x1003) {
# RAW-NEXT: TypeLeafKind: LF_ARGLIST (0x1201)
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
# RAW-NEXT: NumArgs: 1
# RAW-NEXT: Arguments [
# RAW-NEXT: ArgType: 0x0
# RAW-NEXT: ]
# RAW-NEXT: }
# RAW-NEXT: }
# RAW-NEXT: {
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
# RAW-NEXT: Procedure (0x1004) {
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
# RAW-NEXT: TypeLeafKind: LF_PROCEDURE (0x1008)
# RAW-NEXT: ReturnType: int (0x74)
# RAW-NEXT: CallingConvention: NearC (0x0)
# RAW-NEXT: FunctionOptions [ (0x0)
# RAW-NEXT: ]
# RAW-NEXT: NumParameters: 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
# RAW-NEXT: ArgListType: (<no type>) (0x1003)
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
# RAW-NEXT: }
# RAW-NEXT: }
# RAW-NEXT: {
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
# RAW-NEXT: FuncId (0x1005) {
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
# RAW-NEXT: TypeLeafKind: LF_FUNC_ID (0x1601)
# RAW-NEXT: ParentScope: 0x0
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
# RAW-NEXT: FunctionType: int (<no type>) (0x1004)
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
# RAW-NEXT: Name: main
# RAW-NEXT: }
# RAW-NEXT: }
# RAW-NEXT: {
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
# RAW-NEXT: FuncId (0x1006) {
# RAW-NEXT: TypeLeafKind: LF_FUNC_ID (0x1601)
# RAW-NEXT: ParentScope: 0x0
# RAW-NEXT: FunctionType: int () (0x1001)
# RAW-NEXT: Name: foo
# RAW-NEXT: }
# RAW-NEXT: }
# RAW-NEXT: {
# RAW-NEXT: StringId (0x1007) {
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
# RAW-NEXT: TypeLeafKind: LF_STRING_ID (0x1605)
# RAW-NEXT: Id: 0x0
# RAW-NEXT: StringData: D:\b
# RAW-NEXT: }
# RAW-NEXT: }
# RAW-NEXT: {
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
# RAW-NEXT: StringId (0x1008) {
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
# RAW-NEXT: TypeLeafKind: LF_STRING_ID (0x1605)
# RAW-NEXT: Id: 0x0
# RAW-NEXT: StringData: C:\vs14\VC\BIN\amd64\cl.exe
# RAW-NEXT: }
# RAW-NEXT: }
# RAW-NEXT: {
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
# RAW-NEXT: StringId (0x1009) {
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
# RAW-NEXT: TypeLeafKind: LF_STRING_ID (0x1605)
# RAW-NEXT: Id: 0x0
# RAW-NEXT: StringData: -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: }
# RAW-NEXT: }
# RAW-NEXT: {
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
# RAW-NEXT: StringList (0x100A) {
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
# RAW-NEXT: TypeLeafKind: LF_SUBSTR_LIST (0x1604)
# RAW-NEXT: NumArgs: 1
# RAW-NEXT: Arguments [
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
# RAW-NEXT: ArgType: -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" (0x1009)
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
# RAW-NEXT: ]
# RAW-NEXT: }
# RAW-NEXT: }
# RAW-NEXT: {
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
# RAW-NEXT: StringId (0x100B) {
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
# RAW-NEXT: TypeLeafKind: LF_STRING_ID (0x1605)
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
# RAW-NEXT: Id: (-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") (0x100A)
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
# RAW-NEXT: StringData: -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: }
# RAW-NEXT: }
# RAW-NEXT: {
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
# RAW-NEXT: StringId (0x100C) {
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
# RAW-NEXT: TypeLeafKind: LF_STRING_ID (0x1605)
# RAW-NEXT: Id: 0x0
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
# RAW-NEXT: StringData: 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
# RAW-NEXT: }
# RAW-NEXT: }
# RAW-NEXT: {
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
# RAW-NEXT: StringId (0x100D) {
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
# RAW-NEXT: TypeLeafKind: LF_STRING_ID (0x1605)
# RAW-NEXT: Id: 0x0
# RAW-NEXT: StringData: D:\b\vc140.pdb
# RAW-NEXT: }
# RAW-NEXT: }
# RAW-NEXT: {
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
# RAW-NEXT: BuildInfo (0x100E) {
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
# RAW-NEXT: TypeLeafKind: LF_BUILDINFO (0x1603)
# RAW-NEXT: NumArgs: 5
# RAW-NEXT: Arguments [
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
# RAW-NEXT: ArgType: D:\b (0x1007)
# RAW-NEXT: ArgType: C:\vs14\VC\BIN\amd64\cl.exe (0x1008)
# RAW-NEXT: ArgType: ret42-main.c (0x100C)
# RAW-NEXT: ArgType: D:\b\vc140.pdb (0x100D)
# RAW-NEXT: ArgType: -I"C:\Program Files (x86)\Windows Kits\8.1\include\um" -I"C:\Program Files (x86)\Windows Kits\8.1\include\winrt" -TC -X (0x100B)
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
# RAW-NEXT: ]
# RAW-NEXT: }
# RAW-NEXT: }
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
# RAW-NEXT: {
# RAW-NEXT: StringId (0x100F) {
# RAW-NEXT: TypeLeafKind: LF_STRING_ID (0x1605)
# RAW-NEXT: Id: 0x0
# RAW-NEXT: StringData: ret42-sub.c
# RAW-NEXT: }
# RAW-NEXT: }
# RAW-NEXT: {
# RAW-NEXT: BuildInfo (0x1010) {
# RAW-NEXT: TypeLeafKind: LF_BUILDINFO (0x1603)
# RAW-NEXT: NumArgs: 5
# RAW-NEXT: Arguments [
# RAW-NEXT: ArgType: D:\b (0x1007)
# RAW-NEXT: ArgType: C:\vs14\VC\BIN\amd64\cl.exe (0x1008)
# RAW-NEXT: ArgType: ret42-sub.c (0x100F)
# RAW-NEXT: ArgType: D:\b\vc140.pdb (0x100D)
# RAW-NEXT: ArgType: -I"C:\Program Files (x86)\Windows Kits\8.1\include\um" -I"C:\Program Files (x86)\Windows Kits\8.1\include\winrt" -TC -X (0x100B)
# RAW-NEXT: ]
# RAW-NEXT: }
# RAW-NEXT: }
# RAW-NEXT: Hash {
# RAW-NEXT: Number of Hash Buckets: 4096
# RAW-NEXT: Hash Key Size: 4
# RAW-NEXT: Values: []
# RAW-NEXT: Type Index Offsets: []
# RAW-NEXT: Hash Adjustments: []
# RAW-NEXT: }
# RAW-NEXT: ]
# RAW-NEXT: }
# RAW-NEXT: Type Info Stream (IPI) {
# RAW-NEXT: IPI Version: 20040203
# RAW-NEXT: Record count: 0
# RAW-NEXT: Records [
# RAW-NEXT: Hash {
# RAW-NEXT: Number of Hash Buckets: 4096
# RAW-NEXT: Hash Key Size: 4
# RAW-NEXT: Values: []
# RAW-NEXT: Type Index Offsets: []
# RAW-NEXT: Hash Adjustments: []
# RAW-NEXT: }
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
# RAW-NEXT: ]
# RAW-NEXT: }
# RAW-NEXT: DBI Stream {
PDB: Add "* Linker *" module. The added module contains nothing, but it is still useful as a test to ensure that we are emitting modules that can be read back. llvm-svn: 287071
2016-11-16 09:10:46 +08:00
# RAW-NEXT: Dbi Version: 20091201
# RAW-NEXT: Age: 1
# RAW-NEXT: Incremental Linking: No
# RAW-NEXT: Has CTypes: No
# RAW-NEXT: Is Stripped: No
# RAW-NEXT: Machine Type: x86
# RAW-NEXT: Symbol Record Stream Index: 65535
# RAW-NEXT: Public Symbol Stream Index: 65535
# RAW-NEXT: Global Symbol Stream Index: 65535
# RAW-NEXT: Toolchain Version: 0.0
# RAW-NEXT: mspdb00.dll version: 0.0.0
# RAW-NEXT: Modules [
# RAW-NEXT: {
# RAW-NEXT: Name: * Linker *
# RAW-NEXT: Debug Stream Index: 65535
# RAW-NEXT: Object File Name:
# RAW-NEXT: Num Files: 0
# RAW-NEXT: Source File Name Idx: 0
# RAW-NEXT: Pdb File Name Idx: 0
# RAW-NEXT: Line Info Byte Size: 0
# RAW-NEXT: C13 Line Info Byte Size: 0
# RAW-NEXT: Symbol Byte Size: 0
# RAW-NEXT: Type Server Index: 0
# RAW-NEXT: Has EC Info: No
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
# RAW-NEXT: 0 Contributing Source Files [
# RAW-NEXT: ]
PDB: Add "* Linker *" module. The added module contains nothing, but it is still useful as a test to ensure that we are emitting modules that can be read back. llvm-svn: 287071
2016-11-16 09:10:46 +08:00
# RAW-NEXT: }
# RAW-NEXT: ]
# RAW-NEXT: }
# RAW-NEXT: Section Contributions [
Emit Section Contributions. Differential Revision: https://reviews.llvm.org/D26211 llvm-svn: 286684
2016-11-12 08:00:51 +08:00
# RAW-NEXT: Contribution {
# RAW-NEXT: ISect: 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
# RAW-NEXT: Off: 1288
# RAW-NEXT: Size: 14
# RAW-NEXT: Characteristics [ (0x60500020)
# RAW-NEXT: IMAGE_SCN_ALIGN_16BYTES (0x500000)
# RAW-NEXT: IMAGE_SCN_CNT_CODE (0x20)
# RAW-NEXT: IMAGE_SCN_MEM_EXECUTE (0x20000000)
# RAW-NEXT: IMAGE_SCN_MEM_READ (0x40000000)
# RAW-NEXT: ]
# RAW-NEXT: Module {
# RAW-NEXT: Index: 0
# RAW-NEXT: Name: * Linker *
# RAW-NEXT: }
# RAW-NEXT: Data CRC: 0
# RAW-NEXT: Reloc CRC: 0
# RAW-NEXT: }
# RAW-NEXT: Contribution {
# RAW-NEXT: ISect: 0
# RAW-NEXT: Off: 1312
# RAW-NEXT: Size: 8
# RAW-NEXT: Characteristics [ (0x40300040)
# RAW-NEXT: IMAGE_SCN_ALIGN_4BYTES (0x300000)
# RAW-NEXT: IMAGE_SCN_CNT_INITIALIZED_DATA (0x40)
# RAW-NEXT: IMAGE_SCN_MEM_READ (0x40000000)
# RAW-NEXT: ]
# RAW-NEXT: Module {
# RAW-NEXT: Index: 0
# RAW-NEXT: Name: * Linker *
# RAW-NEXT: }
# RAW-NEXT: Data CRC: 0
# RAW-NEXT: Reloc CRC: 0
# RAW-NEXT: }
# RAW-NEXT: Contribution {
# RAW-NEXT: ISect: 0
# RAW-NEXT: Off: 1320
# RAW-NEXT: Size: 12
# RAW-NEXT: Characteristics [ (0x40300040)
# RAW-NEXT: IMAGE_SCN_ALIGN_4BYTES (0x300000)
# RAW-NEXT: IMAGE_SCN_CNT_INITIALIZED_DATA (0x40)
# RAW-NEXT: IMAGE_SCN_MEM_READ (0x40000000)
# RAW-NEXT: ]
# RAW-NEXT: Module {
# RAW-NEXT: Index: 0
# RAW-NEXT: Name: * Linker *
# RAW-NEXT: }
# RAW-NEXT: Data CRC: 0
# RAW-NEXT: Reloc CRC: 0
# RAW-NEXT: }
# RAW-NEXT: Contribution {
# RAW-NEXT: ISect: 0
# RAW-NEXT: Off: 1144
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
# RAW-NEXT: Size: 6
# RAW-NEXT: Characteristics [ (0x60500020)
# RAW-NEXT: IMAGE_SCN_ALIGN_16BYTES (0x500000)
Emit Section Contributions. Differential Revision: https://reviews.llvm.org/D26211 llvm-svn: 286684
2016-11-12 08:00:51 +08:00
# RAW-NEXT: IMAGE_SCN_CNT_CODE (0x20)
# RAW-NEXT: IMAGE_SCN_MEM_EXECUTE (0x20000000)
# RAW-NEXT: IMAGE_SCN_MEM_READ (0x40000000)
# RAW-NEXT: ]
# RAW-NEXT: Module {
# RAW-NEXT: Index: 0
PDB: Add "* Linker *" module. The added module contains nothing, but it is still useful as a test to ensure that we are emitting modules that can be read back. llvm-svn: 287071
2016-11-16 09:10:46 +08:00
# RAW-NEXT: Name: * Linker *
Emit Section Contributions. Differential Revision: https://reviews.llvm.org/D26211 llvm-svn: 286684
2016-11-12 08:00:51 +08:00
# RAW-NEXT: }
# RAW-NEXT: Data CRC: 0
# RAW-NEXT: Reloc CRC: 0
# RAW-NEXT: }
# RAW-NEXT: ]
# RAW-NEXT: Section Map [
# RAW-NEXT: Entry {
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
# RAW-NEXT: Flags [ (0x109)
# RAW-NEXT: AddressIs32Bit (0x8)
# RAW-NEXT: IsSelector (0x100)
# RAW-NEXT: Read (0x1)
# RAW-NEXT: ]
# RAW-NEXT: Ovl: 0
# RAW-NEXT: Group: 0
# RAW-NEXT: Frame: 1
# RAW-NEXT: SecName: 65535
# RAW-NEXT: ClassName: 65535
# RAW-NEXT: Offset: 0
# RAW-NEXT: SecByteLength: 12
# RAW-NEXT: }
# RAW-NEXT: Entry {
Emit Section Contributions. Differential Revision: https://reviews.llvm.org/D26211 llvm-svn: 286684
2016-11-12 08:00:51 +08:00
# RAW-NEXT: Flags [ (0x10D)
# RAW-NEXT: AddressIs32Bit (0x8)
Re-commit r285607: Emit Section Map stream." Removed some test fields that overspecified test conditions. llvm-svn: 285638
2016-11-01 05:09:21 +08:00
# RAW-NEXT: Execute (0x4)
# RAW-NEXT: IsSelector (0x100)
# RAW-NEXT: Read (0x1)
# RAW-NEXT: ]
# RAW-NEXT: Ovl: 0
# RAW-NEXT: Group: 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
# RAW-NEXT: Frame: 2
Re-commit r285607: Emit Section Map stream." Removed some test fields that overspecified test conditions. llvm-svn: 285638
2016-11-01 05:09:21 +08:00
# RAW-NEXT: SecName: 65535
# RAW-NEXT: ClassName: 65535
# RAW-NEXT: Offset: 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
# RAW-NEXT: SecByteLength: 22
Re-commit r285607: Emit Section Map stream." Removed some test fields that overspecified test conditions. llvm-svn: 285638
2016-11-01 05:09:21 +08:00
# RAW-NEXT: }
# RAW-NEXT: Entry {
# RAW-NEXT: Flags [ (0x109)
# RAW-NEXT: AddressIs32Bit (0x8)
# RAW-NEXT: IsSelector (0x100)
# RAW-NEXT: Read (0x1)
# RAW-NEXT: ]
# RAW-NEXT: Ovl: 0
# RAW-NEXT: Group: 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
# RAW-NEXT: Frame: 3
Re-commit r285607: Emit Section Map stream." Removed some test fields that overspecified test conditions. llvm-svn: 285638
2016-11-01 05:09:21 +08:00
# RAW-NEXT: SecName: 65535
# RAW-NEXT: ClassName: 65535
# RAW-NEXT: Offset: 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
# RAW-NEXT: SecByteLength: 8
# RAW-NEXT: }
# RAW-NEXT: Entry {
# RAW-NEXT: Flags [ (0x109)
# RAW-NEXT: AddressIs32Bit (0x8)
# RAW-NEXT: IsSelector (0x100)
# RAW-NEXT: Read (0x1)
# RAW-NEXT: ]
# RAW-NEXT: Ovl: 0
# RAW-NEXT: Group: 0
# RAW-NEXT: Frame: 4
# RAW-NEXT: SecName: 65535
# RAW-NEXT: ClassName: 65535
# RAW-NEXT: Offset: 0
# RAW-NEXT: SecByteLength: 101
Re-commit r285607: Emit Section Map stream." Removed some test fields that overspecified test conditions. llvm-svn: 285638
2016-11-01 05:09:21 +08:00
# RAW-NEXT: }
# RAW-NEXT: Entry {
# RAW-NEXT: Flags [ (0x208)
# RAW-NEXT: AddressIs32Bit (0x8)
# RAW-NEXT: IsAbsoluteAddress (0x200)
# RAW-NEXT: ]
# RAW-NEXT: Ovl: 0
# RAW-NEXT: Group: 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
# RAW-NEXT: Frame: 5
Re-commit r285607: Emit Section Map stream." Removed some test fields that overspecified test conditions. llvm-svn: 285638
2016-11-01 05:09:21 +08:00
# RAW-NEXT: SecName: 65535
# RAW-NEXT: ClassName: 65535
# RAW-NEXT: Offset: 0
# RAW-NEXT: SecByteLength: 4294967295
# RAW-NEXT: }
# RAW-NEXT: ]
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
# RAW-NEXT: Globals Stream not present
# RAW-NEXT: Publics Stream not present
Re-commit r285607: Emit Section Map stream." Removed some test fields that overspecified test conditions. llvm-svn: 285638
2016-11-01 05:09:21 +08:00
# RAW-NEXT: Section Headers [
Re-submit r283825: Add section header stream to PDB. It was reverted because the change that depends on was reverted. Now it was submitted as r283925, so we can submit this as well. llvm-svn: 283926
2016-10-12 03:45:07 +08:00
# RAW-NEXT: {
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
# RAW-NEXT: Name: .pdata
# RAW-NEXT: Virtual Size: 12
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
# RAW-NEXT: Virtual Address: 4096
# RAW-NEXT: Size of Raw Data: 512
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
# RAW-NEXT: File Pointer to Raw Data: 1024
# RAW-NEXT: File Pointer to Relocations: 0
# RAW-NEXT: File Pointer to Linenumbers: 0
# RAW-NEXT: Number of Relocations: 0
# RAW-NEXT: Number of Linenumbers: 0
# RAW-NEXT: Characteristics [ (0x40000040)
# RAW-NEXT: IMAGE_SCN_CNT_INITIALIZED_DATA (0x40)
# RAW-NEXT: IMAGE_SCN_MEM_READ (0x40000000)
# RAW-NEXT: ]
# RAW-NEXT: }
# RAW-NEXT: {
# RAW-NEXT: Name: .text
# RAW-NEXT: Virtual Size: 22
# RAW-NEXT: Virtual Address: 8192
# RAW-NEXT: Size of Raw Data: 512
# RAW-NEXT: File Pointer to Raw Data: 1536
Re-submit r283825: Add section header stream to PDB. It was reverted because the change that depends on was reverted. Now it was submitted as r283925, so we can submit this as well. llvm-svn: 283926
2016-10-12 03:45:07 +08:00
# RAW-NEXT: File Pointer to Relocations: 0
# RAW-NEXT: File Pointer to Linenumbers: 0
# RAW-NEXT: Number of Relocations: 0
# RAW-NEXT: Number of Linenumbers: 0
# RAW-NEXT: Characteristics [ (0x60000020)
# RAW-NEXT: IMAGE_SCN_CNT_CODE (0x20)
# RAW-NEXT: IMAGE_SCN_MEM_EXECUTE (0x20000000)
# RAW-NEXT: IMAGE_SCN_MEM_READ (0x40000000)
# RAW-NEXT: ]
# RAW-NEXT: }
# RAW-NEXT: {
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
# RAW-NEXT: Name: .xdata
# RAW-NEXT: Virtual Size: 8
# RAW-NEXT: Virtual Address: 12288
# RAW-NEXT: Size of Raw Data: 512
# RAW-NEXT: File Pointer to Raw Data: 2048
# RAW-NEXT: File Pointer to Relocations: 0
# RAW-NEXT: File Pointer to Linenumbers: 0
# RAW-NEXT: Number of Relocations: 0
# RAW-NEXT: Number of Linenumbers: 0
# RAW-NEXT: Characteristics [ (0x40000040)
# RAW-NEXT: IMAGE_SCN_CNT_INITIALIZED_DATA (0x40)
# RAW-NEXT: IMAGE_SCN_MEM_READ (0x40000000)
# RAW-NEXT: ]
# RAW-NEXT: }
# RAW-NEXT: {
Re-submit r283825: Add section header stream to PDB. It was reverted because the change that depends on was reverted. Now it was submitted as r283925, so we can submit this as well. llvm-svn: 283926
2016-10-12 03:45:07 +08:00
# RAW-NEXT: Name: .rdata
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
# RAW-NEXT: Virtual Size: 101
# RAW-NEXT: Virtual Address: 16384
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
# RAW-NEXT: Size of Raw Data: 512
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
# RAW-NEXT: File Pointer to Raw Data: 2560
Re-submit r283825: Add section header stream to PDB. It was reverted because the change that depends on was reverted. Now it was submitted as r283925, so we can submit this as well. llvm-svn: 283926
2016-10-12 03:45:07 +08:00
# RAW-NEXT: File Pointer to Relocations: 0
# RAW-NEXT: File Pointer to Linenumbers: 0
# RAW-NEXT: Number of Relocations: 0
# RAW-NEXT: Number of Linenumbers: 0
# RAW-NEXT: Characteristics [ (0x40000040)
# RAW-NEXT: IMAGE_SCN_CNT_INITIALIZED_DATA (0x40)
# RAW-NEXT: IMAGE_SCN_MEM_READ (0x40000000)
# RAW-NEXT: ]
# RAW-NEXT: }
# RAW-NEXT: ]
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
# RAW-NEXT: New FPO [
# RAW-NEXT: ]