[PATCH] D20435: [codeview] Adding support for CodeView types

[Amjad Aboud via llvm-commits]

aaboud added a comment.

Hi Reid,

> Today the metadata we generate does not mention B at all, and that is a problem we're going to have to fix if we want our type records to be bitwise identical across TUs. I think we should change clang to mention a forward declaration of B in the elements list of A, and then we don't need to go back and patch up existing type records.


I wanted to show you that the current debug info metadata contain (almost) everything we need to generate codeview types and symbols.
The reason you keep thinking that we need to change the metadata is that you decided on this implementation direction.

> I assume the way we support types in PDBs is by doing synchronous IPCs or file IO at the point of the call to TypeTableBuilder::writeRecord. Is that not similar to what MSVC does?


If we will end up emitting the type record to the pdb file at "TypeTableBuilder::writeRecord", then I assume we will get the correct index after all, but can we do that when supporting pdb files? and if so, why not do that for COFF files two?

---

Finally, one minor issue regarding debuggablity and testing, are we fine to get ".debug$T" section printed in assembly mode like this, instead of have each "Type record data" string split and explained by field?

  .section        .debug$T,"dr"
  .long   4                       # Debug section magic
  .short  6                       # Type record length
  .asciz  "\001\022\000\000\000"  # Type record data
  .short  14                      # Type record length
  .asciz  "\b\020\003\000\000\000\000\000\000\000\000\020\000" # Type record data
  .short  12                      # Type record length
  .asciz  "\001\026\000\000\000\000\001\020\000\000f" # Type record data


http://reviews.llvm.org/D20435