dblaikie added a comment. In D96778#2576913 <https://reviews.llvm.org/D96778#2576913>, @jankratochvil wrote:
> In D96778#2576881 <https://reviews.llvm.org/D96778#2576881>, @dblaikie wrote: > >> In D96778#2573076 <https://reviews.llvm.org/D96778#2573076>, @jankratochvil >> wrote: >> >>> Personally I am not interested in DWZ, I am implementing it only as a >>> compatibility with existing file format, IMNSHO DWZ should be dropped. >> >> Not sure I follow. dwz does use the existing DWARF file format. you mean >> you're only interested in compatibility with the DWARF directly produced by >> compilers, not post-processed by dwz? Fair enough. I guess @werat has some >> interest in supporting dwz for their use cases. > > No, I need compatibility of LLDB with DWZ (or rather LLDB needs it if it > should get used on Red Hat systems). Ah, OK. You want RH compatibility. RH uses DWZ. You'd rather they didn't, but working with it, given they still do use it. > DWZ is specified by DWARF-5 What part of DWZ is specified by DWARFv5? My understanding is that DWZ uses existing standard features/didn't need anything in particular standardized in any DWARF version (perhaps the original creation of partial units was motivated by DWZ? But partial units have been around for a few versions - seems like it was introduced in DWARFv3) > but there are various DWARF tools still not supporting DWZ. DWARF is a very broad (as they like to say, "permissive") standard. Lots of valid DWARF won't work in lots of places, because the full spectrum of interesting ways one could use DWARF features is too broad to be uniformly implemented - generally consumers and produces implement enough to work with each other and that's about it. (for instance I recently started dabbling with a feature that would use DW_AT_ranges on DW_TAG_subprograms - totally valid DWARF, but unsurprisingly, DWARF consumers that'd never had to deal with DWARF like this before didn't have support for it (lldb, in particular - had partial support, hopefully it's got full support for at least single-length DW_AT_ranges, but I think last I checked there were still issues with multi-element ranges)) > Also the only DWZ format currently in use is a non-standard GNU extension of > DWARF-4. Which extensions would those be? At a glance when looking at the small dwz example earlier I didn't notice any DWARF extensions. (though, in any case, we deal with extensions on a pretty regular basis - see all the DWARFv4 + Split DWARF work, for instance (& then the call_site/call_site_parameter stuff, etc)) > The DWZ format has been designed for GDB making it difficult to parse it by > LLDB. LLDB does per-DIE DWARF->IR conversion compared to GDB doing per-CU > DWARF->IR conversion, that means that LLDB needs to keep context of the DWZ > parent DIE (as DWZ recursively imports DW_TAG_partial_unit) for each its > reference of DIE in its various indices which is a PITA. (probably best to leave out the 'PITA'/swear/colourful language) 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? 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
