jankratochvil added a comment. In D96778#2576927 <https://reviews.llvm.org/D96778#2576927>, @dblaikie wrote:
> What part of DWZ is specified by DWARFv5? `DW_*_sup` being used by DWZ with DWARF-4 as `DW_*_GNU_*_alt` (and dwarfstd.org proposal <https://webcache.googleusercontent.com/search?q=cache:qSMqeKD7ej0J:www.dwarfstd.org/ShowIssue.php%3Fissue%3D120604.1+&cd=2&hl=en&ct=clnk&gl=cz&lr=lang_en> having it as `DW_*_alt`) for DWZ common files located in `/usr/lib/debug/.dwz/` where each file is for one rpm package sharing DIEs to multiple *.debug files of the same rpm package. That is probably all but I cannot check more as www.dwarfstd.org <http://www.dwarfstd.org> is down now. > (perhaps the original creation of partial units was motivated by DWZ? Rather DWZ was motivated by partial units IMO. > Which extensions would those be? Those `DW_*_alt`/`DW_*_sup` ones. > At a glance when looking at the small dwz example earlier I didn't notice any > DWARF extensions. This example is not using the DWZ common file (that makes sense only for >=2 `*.debug` files). Still `DW_TAG_partial_unit`, `DW_AT_import` etc. is used only by DWZ and AFAIK no other tool so it needs extra implementation in all the tools incl. LLDB. > I'm not sure I follow the description here - when generating Clang ASTs from > some DIE in LLDB, one would still have to potentially pass through multiple > CUs to retrieve all the relevant types, especially under any form of LTO - > are there particular features of DWZ that make this more/differently > problematic? If you have a reference to DIE then LLDB tries to ask for `DW_AT_language` of its CU. But if the DIE is in `DW_TAG_partial_unit` (PU) there is no `DW_AT_language` and you do not know which CU did use `DW_TAG_imported_unit->DW_AT_import` for that PU. Moreover the `DW_TAG_partial_unit` can be imported by two different CUs one having `DW_AT_language` as C and the other as C++. That is IMO a bug, each PU should have its `DW_AT_language` and then PU with different language would be separate. Still such format change would not help much as `DWARFASTParser`, `CompilerDeclContext` and similar stuff needs to come from the parent CU as otherwise LLDB all breaks down when some DIEs (from `DW_AT_partial_unit` possibly even from DWZ common file) come from a different AST. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D96778/new/ https://reviews.llvm.org/D96778 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
