> On Mar 16, 2015, at 2:55 PM, David Blaikie <[email protected]> wrote:
>
>
>
>> On Mon, Mar 16, 2015 at 2:45 PM, Robinson, Paul
>> <[email protected]> wrote:
> Beyond the above (that using a new tag would mean this would go from 'free'
> to 'not free' for GDB) having a new top level tag is pretty substantial (we
> only have two at the moment, and with our talk of modules being a "bag of
> dwarf" might go back to having one top level tag? (it's not clear to me from
> DWARF4 whether DW_TAG_module is currently a top-level tag, I don't think it
> is?)
>
>> The .debug_info section contains one or more compilation units, partial
>> units, or in DWARF 5, type units. DW_TAG_module isn't a unit, if you want
>> it to be handled independently then it would need to be wrapped in a
>> DW_TAG_partial_unit. You would probably then use DW_TAG_imported_unit to
>> refer to it, rather than DW_TAG_imported_module.
>>
>
> This makes a fair bit of sense - though the terminology's never going to
> quite line up with modules, I suspect, and this would still require modifying
> existing consumers (well, GDB) that can handle split-dwarf today, I suspect
> (not sure how it'd handle partial_unit - maybe that does work? - and still
> don't know how existing consumers would handle imported_unit either - could
> be worth some testing, as it sounds sort of right out of several less right
> options).
Thanks for all the input so far!
To concretize this end of the discussion up let’s sketch some dwarf of how this
could look like in practice.
ELF (no imports)
----------------
On ELF or COFF a foo.c referencing types from the module Foundation looks like
this:
.debug_info:
DW_TAG_compile_unit
DW_AT_name(“foo.c”)
.debug_info.dwo (on ELF: group 0x1234ABCDE, comdat)
DW_TAG_partial_unit
DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”)
DW_AT_dwo_id(“0x1234ABCDE”)
Side question: Is .debug_info.dwo the right section to put the module skeleton
in, or should it be a .debug_info section like normal fission skeletons?
Mach-O (no comdat, no imports)
------------------------------
Mach-O doesn’t do comdat, so with -split-dwarf=Disable (not sure if that option
is the best discriminator) this could look like:
.debug_info:
DW_TAG_compile_unit
DW_AT_name(“foo.c”)
DW_TAG_partial_unit
DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”)
DW_AT_dwo_id(“0x1234ABCDE”)
Mach-O (no comdat, with imports)
------------------------------
If we add the module import information to this, we get:
.debug_info:
DW_TAG_compile_unit
DW_AT_name(“foo.c”)
DW_TAG_imported_module
DW_AT_import(DW_FORM_ref_addr 0x10)
DW_TAG_partial_unit
DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”)
DW_AT_dwo_id(“0x1234ABCDE”)
0x10:
DW_TAG_module
DW_AT_name(“Foundation”)
DW_AT_LLVM_sysroot(“/“)
DW_AT_LLVM_include_dir(“”)
DW_AT_LLVM_macros(“-DNDEBUG”)
...
ELF (comdat, with imports)
--------------------------
But now let’s go back to ELF. Since the skeleton with the partial unit is
comdat'd, I assume that this breaks the FORM_ref_addr used in the DW_AT_import.
We could reuse the module hash as a signature for the module:
.debug_info:
DW_TAG_compile_unit
DW_AT_name(“foo.c”)
DW_TAG_imported_module
DW_AT_import(DW_FORM_ref_addr 0x1234ABCDE)
.debug_info.dwo (group 0x1234ABCDE, comdat)
DW_TAG_partial_unit
DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”)
DW_AT_dwo_id(“0x1234ABCDE”)
DW_TAG_module
DW_AT_signature(“0x1234ABCDE”)
DW_AT_name(“Foundation”)
This is bending the definition of DW_AT_signature, but I guess it could be made
to work. Or we could say that for now, users have to choose between the comdat
optimization and having the module imports recorded in Dwarf, since GDB
wouldn’t know what to do with that information anyway.
Thoughts?
-- adrian
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
