[PATCH] Add a DWOId field to DICompileUnit (so DWARF skeleton CUs can be expression in IR).

[Adrian Prantl]

> On May 4, 2015, at 1:46 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> And this is the part of the recent debug info schema changes that makes me a bit sad - the amount of code that has to change to add a field to a debug info record... that's a lot of files to touch, etc. :/
> 
> On Mon, May 4, 2015 at 12:58 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
> Hi dexonsmith, dblaikie, echristo,
> 
> This patch adds a DWOId field to DICompileUnit so DWARF skeleton CUs can be expression in IR.

Looks like phabricator swallowed everything after the first paragraph :-(

> We might want to call this ModuleId - normal DWOs won't have a DWOId passed down from the frontend (because it's computed in the backend by hashing the contents of the debug_info in the .dwo file). But maybe DWOId is fine - not sure, just throwing some ideas around.

The other name that I was thinking about was SplitDebugID, for symmetry with SplitDebugFilename. But who are we kidding... LLVM’s debug IR is effectively DWARF, so we may as well reduce the confusion and name things after their DWARF counterparts.

> I suppose this will be used on both sides of the module+fission work - passed down for a non-trivial CU when building the module's debug info itself.

Originally I thought that it would be passed down when building the module, too. But then I learned that Clang’s ModuleId currently is just a random number and that generating the DWARF dwo signature is actually better here, because it’s at least reproducible.

> Then also passed down attached to a trivial CU when building the skeleton CU to reference the module? (in the latter case, it'll need to be used for the comdat group identifier too - we'll need some way to differentiate these two cases, then? as well as including all the special llvm attributes for module reconstitution (pending where they actually end up))

Although not needed for this particular issue (we can generate a DWARF signature), I will also post a patch to introduce a ClangModule EmissionKind to deal with the few but subtle differences in emitting debug info for a module.

-- adrian

>  
> A skeleton CU is a (typically empty) DW_TAG_compile_unit that has a DW_AT_(GNU)_dwo_name and a DW_AT_(GNU)_dwo_id attribute. It is used to refer to external debug info.
> 
> This is a prerequisite for clang module debugging as discussed in http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-November/040076.html <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-November/040076.html>.
> In order to refer to external types stored in split DWARF (dwo) objects, such as clang modules, we need to emit skeleton CUs, which identify the dwarf object (i.e., the clang module) by filename (the SplitDebugFilename) and a hash value, the dwo_id.
> 
> This patch only contains the IR changes. The idea is that a CUs with a non-zero dwo_id field will be emitted together with a DW_AT_GNU_dwo_name and DW_AT_GNU_dwo_id attribute.
> 
> REPOSITORY
>   rL LLVM
> 
> http://reviews.llvm.org/D9488 <http://reviews.llvm.org/D9488>
> 
> Files:
>   include/llvm/IR/DIBuilder.h
>   include/llvm/IR/DebugInfoMetadata.h
>   lib/AsmParser/LLParser.cpp
>   lib/Bitcode/Reader/BitcodeReader.cpp
>   lib/Bitcode/Writer/BitcodeWriter.cpp
>   lib/IR/AsmWriter.cpp
>   lib/IR/DIBuilder.cpp
>   lib/IR/DebugInfoMetadata.cpp
>   lib/IR/LLVMContextImpl.h
>   test/Assembler/mdcompileunit.ll
>   unittests/IR/MetadataTest.cpp
> 
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/ <http://reviews.llvm.org/settings/panel/emailpreferences/>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150504/1426db1e/attachment.html>