June 29, 2015 [dmd-internals] [DWARF] Correct approach for adding module/import support | ||||
---|---|---|---|---|
| ||||
Hi, I've received no comment whatsoever despite repeated pings. https://github.com/D-Programming-Language/dmd/pull/4746 https://github.com/D-Programming-Language/dmd/pull/4750 https://github.com/D-Programming-Language/dmd/pull/4773 This is pretty much the rough summary of what I want to mimic in DMD. PR #4746: - 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. PR #4750: - 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. PR #4773: - 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 Symbol. 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. Iain. _______________________________________________ dmd-internals mailing list dmd-internals@puremagic.com http://lists.puremagic.com/mailman/listinfo/dmd-internals |
Copyright © 1999-2021 by the D Language Foundation