[dmd-internals] [DWARF] Correct approach for adding module/import support
Iain Buclaw via dmd-internals
dmd-internals at puremagic.com
Mon Jun 29 02:36:01 PDT 2015
Hi, I've received no comment whatsoever despite repeated pings.
This is pretty much the rough summary of what I want to mimic in DMD.
- Modules are emitted as DW_TAG_module
- External modules (not being compiled) are correctly marked as external.
- Module being emitted are marked as having children, and all symbols
that are part of that module are emitted into it, with exception to
- Symbols that are not extern(D), in which case they are declared as
being outside the module.
- Imported modules, selective imports, and renamed imports are emitted
as DW_TAG_imported_declaration, this requires that
- All imported modules and declarations for the current compiled
module are declared in debug, as extern symbols unless we are
compiling for them too.
- Associate a DW_TAG_module to a Symbol, which is in turn associated
with a Module
- Re-introduce ModuleInfoDeclaration, and move the generation of
ModuleInfo out of Module and into the correctly named frontend type.
PR 4746 is trivial as all modules are emitted as one-at-a-time. There
are only two non-trivial-but-simple-enough cases to address in the PR:
- Firstly, extern(C) or extern(C++) symbols, which must be delayed
until after the module has finished.
- Secondly, all extern(D) statics and __gshared symbols nested in
functions/types, which must be emitted as a child of the module, not a
child of the enclosing function/type.
PR 4750 is more difficult as it requires that we now must keep track
of Modules. So we now need a way to associate them with a backend
PR 4773 is an attempt at implementing the first part of what is needed
for #4750, but it needs some direction.
Any input? I'm at the stage where I will be submitting patches to
gdb, if nothing is done on the compiler side, then debugging
experience of DMD compiled programs will go downhill very quickly.
More information about the dmd-internals