[PATCH] D45283: [COFF] Minimal serialization support for precompiled types records

Alexandre Ganea via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 5 08:29:34 PDT 2018


aganea marked an inline comment as done.
aganea added inline comments.


================
Comment at: include/llvm/DebugInfo/CodeView/TypeRecord.h:910
+
+  uint32_t StartTypeIndex;
+  uint32_t TypesCount;
----------------
rnk wrote:
> That sounds like it'll be fun to implement in type merging. =/
Well in practice, it is not as bad as it seems. It boils down to replacing the LF_PRECOMP record with a copy of precomp.obj, up to LF_ENDRECORD.

Consider a.obj, which has a reference to precomp.obj:


```
0x1000 | LF_PRECOMP [size = 60] start index = 4096, types count = 1031, signature = 0x1116980E, precomp path = f:\svn\lld\test\coff\precomp\precomp.obj
0x1407 | LF_ARGLIST [size = 12]
         0x0070 (char): `char`
0x1408 | LF_PROCEDURE [size = 16]
         return type = 0x0074 (int), # args = 1, param list = 0x1407
         calling conv = cdecl, options = None
0x1409 | LF_FUNC_ID [size = 20]
         name = main, type = 0x1029, parent scope = <no type>
```
and precomp.obj:

```
0x1000 | LF_STRUCTURE [size = 64] `_s__CatchableType`
         unique name: `.?AU_s__CatchableType@@`
         vtable: <no type>, base list: <no type>, field list: <no type>
         options: forward ref | has unique name
0x1001 | LF_MODIFIER [size = 12]
         referent = 0x1000, modifiers = const
...
0x1406 | LF_UDT_SRC_LINE [size = 16]
         udt = 0x1405, file = 4180, line = 759
0x1407 | LF_ENDPRECOMP [size = 8] signature = 0x1116980E
```

Prior to merging a.obj, you simply append the contents of precomp.obj into LF_PRECOMP, up to LF_ENDPRECOMP (but not including it)
As you can see the type records IDs jump after LF_PRECOMP from 0x1000 to 0x1407. The data is just here for back-reference, so a.obj can be remapped properly. We only merge/remap precomp.obj once.

Currently, llvm-pdbutil does not jump from 0x1000 to 0x1407 after printing LF_PRECOMP, I will fix that in a subsequent change as it doesn't seem like a trivial change.


Repository:
  rL LLVM

https://reviews.llvm.org/D45283





More information about the llvm-commits mailing list