[LLVMdev] [patch] Prototype/proof-of-concept for DWARF type units

David Blaikie dblaikie at gmail.com
Mon Sep 30 14:34:22 PDT 2013


This isn't a realistic/viable implementation, just a hacked up "can I make
it produce the right output" kind of thing, but while I hammer out a few
more details (like fixing MC to allow multiple sections with the same name
but different comdat groups) I figured I'd throw it out there to have a bit
of a chat about it.

I've tested simple cases of a single type and they seem to work OK.
Multiple types from the same translation unit won't work at the moment due
to the MC issue.

The practical details are fairly simple. When CompileUnit goes to create a
type, first it hands it off to DwarfDebug to decide whether it's going to
be in a type unit. If it is, DwarfDebug spins up a new CompileUnit that's
really a type unit, emits the type into that unit (creating all dependent
types and other paraphernalia), attaches the signature (using the ODR hash
as a stand-in for now) and offset to the CompileUnit and the signature to
the DIE the original CompileUnit provided (along with any other DIEs that
needed that signature and were discovered along the way).

Then emit it as normal - with a few special cases to add the necessary
extra headers, offsets, etc.

A realistic implementation probably involves moving unit header handling
down into CompileUnit, extracting most of the common functionality into a
Unit type and having CompileUnit and TypeUnit types to handle the header
differences. Sound about right?

I haven't got to looking at how this is meant to (or currently does)
interact with fission, but I suspect it might be pretty close 'for free'.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130930/005c191d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: type_units.diff
Type: application/octet-stream
Size: 24606 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130930/005c191d/attachment.obj>


More information about the llvm-dev mailing list