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

[Reid Kleckner via llvm-commits]

rnk added a comment.

In http://reviews.llvm.org/D20435#437656, @aaboud wrote:

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


Well, I think my example shows that we *must* change our type emission to at least mention A::B. I also think it would be convenient to make A reference A::B, so that we don't have to do a complete module pass over all DIType nodes.

> > 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?


I'm not sure I understand the question, but yes, I claim we can get correct type indices at the point of the writeRecord call. We can do it today when building type info streams in memory, and we can do it in the future by looking the type up in the PDB on-disk type hash table.

> 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?


I'd like to improve on this by doing the following, as mentioned previously: "... emit each record as a sequence of 32-bit hex integers preceded by a big block comment generated by the same type dumper that llvm-readobj and llvm-pdbdump use."


http://reviews.llvm.org/D20435