[llvm-dev] [cfe-dev] RFC: CodeView debug info emission in Clang/LLVM

[Reid Kleckner via llvm-dev]

On Fri, Oct 30, 2015 at 8:06 PM, David Blaikie via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
>
> If this is the right idea, lets do it for dwarf too & generalize the
> support to work for both. It's certainly something we've considered, to
> save all the complexity of representing essentially static data in an
> intermediate form.
>
> That said, given some of the stuff we have for lto, for example
> (deallocating/merging types etc) I'm not sure that's obviously the right
> strategy.
>
Similar but different to LTO, LLD is also going to have to do to
deduplicate type records when it reads in .debug$T sections to spit out a
PDB. We probably want to make the LLVM CodeView library useful for handling
that task.

One question for Dave B is, what algorithms does the VC++ linker use to
deduplicate types? The general problem is graph isomorphism, but surely the
linker takes some shortcuts to merge most duplicate debug info without
spending too much time on it.

I should also state up front that I'm mostly interested in pursuing the /Z7
debug info design in upstream clang, and not /Zi, which incrementally
writes PDBs from the compiler. It would be really hard to teach clang how
to do IPC with mspdbsrv or coordinate concurrent updates to the PDB on-disk.

-----

Personally, I'm not sure that merging CV type info into our existing DI
hierarchy is the right way to go. Looking over the CV types in
http://reviews.llvm.org/D14209 suggests that they have a fair amount of
extra information that seems irrelevant to DWARF types. If we were to try
to use a uniform representation for DWARF and CV types, we might want to
follow David's suggestion to make it more opaque, or we'll end up with a
bunch of dead fields in the DI hierarchy.

I think Duncan considered and discarded the idea of putting most type
information into an MDString earlier this year. The current representation
is a lot easier to read and therefore test.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151103/fc17ffe8/attachment.html>