[PATCH] D14209: CodeView type info support preview (LLVM portion)

Eric Christopher via llvm-commits llvm-commits at lists.llvm.org
Thu Nov 19 17:11:59 PST 2015


echristo added a subscriber: echristo.
echristo added a comment.

Hi All,

I appreciate the code drop with the general direction you've been going. It'll help iron out a lot of the direction here.

A way to start here will probably to get a lot of the constants and definitions in by writing a codeview dumping system similar to llvm-dwarfdump. That way as the rest of code view support is added we'll be able to get testcases added in a much better way.

A few questions in general:

Why are codeview types split out as a separate top level entity? It seems this is to support the front end writing out types completely, but a few questions (admittedly without reading the spec, I apologize in advance):

  Do types in code view not need to be able to reference things outside of themselves? i.e. a method function referencing a concrete instance.
  Do types in code view not need to have parts of them referenced from outside? i.e. method functions

We've had some ideas (and gone down a bit) of the path of having dwarf largely emitted by the front end but the need for some of these references makes a huge difference. Is there something about the format that causes this to be unnecessary here?

Some nits (I know you said it wasn't ready for review, but I'll get some of them early):

a) Formatting. Please use clang-format on all new code.
b) I'm not a fan of having to have codeview::TypeIndex() everywhere. Could we refactor this in a different way? I'm trying to keep the internal representation as format neutral as possible and think we're a lot of the way there. If it helps as part of this we can take the formats and define custom "tags" for the metadata that work for each format.

Anyhow, some thoughts while you're working through things.

-eric


http://reviews.llvm.org/D14209





More information about the llvm-commits mailing list