On Thu, Mar 19, 2015 at 5:24 PM, Adrian Prantl <[email protected]> wrote:
> > > 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 > For now I'd suggest we use compile_unit - that way it'll just work with existing split-dwarf consumers. We can see about standardizing a top-level DW_TAG_module or using DW_TAG_partial_unit here later, perhaps? I'm not sure. > > 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? > Skeletons go in .debug_info, the dwo sections are just for the .dwo file (or the module file, in our new case - the extension isn't actually important). It might be worth you compiling an example or two of split-dwarf to see how this all works hands-on. > 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) > Since we got went down the tangent of explaining split-dwarf many emails ago, I've forgotten (& can't readily find) what we were discussing about what ways the imported_module could work. The simplest representation I can think of would be to have it reference, by signature, the module unit (whatever tag it uses) - DW_FORM_ref_sig8, seems the simplest thing to do. > > DW_TAG_partial_unit > > DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) > DW_AT_dwo_id(“0x1234ABCDE”) > > 0x10: > This is inside the partial unit? I figured we'd just put these attributes on the top level (compile_unit, or whatever it might be later) - potentially conditionalized on platform, sure. > 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) > Still only really need these imported_modules for lldb, right? I'd consider having them off-by-default for non-darwin, but I'm not strictly wedded to that notion. Wouldn't mind seeing size impact numbers of some kind - if it's really fractional % increase & GDB doesn't fall over when it sees them (in whatever FORM/tag/etc we decide on) then that's not the end of the world. Just seems nice if the default mode is the nice, standard, split-dwarf output. Doesn't need anything fancy. > > .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”) > > The thing you haven't covered is the actual .dwo sections (.debug_info.dwo (we'll probably need a simple stub compile_unit to make this correct split-dwarf) and .debug_types.dwo being important - but all the supporting .dwo sections will be necessary) that go in the module file. > 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
