On Wed, 11 Apr 2018 00:22:45 +0200, Greg Clayton wrote: > > On Apr 10, 2018, at 2:38 PM, Jan Kratochvil <jan.kratoch...@redhat.com> > > wrote: > > Not only that. Even when DWZ does not use any external file then one > > DW_TAG_partial_unit is included into many DW_TAG_compile_unit and so DIEs > > from > > that DW_TAG_partial_unit would no longer have unique lldb::user_id_t. > > (Although maybe that can be solved by that AST import which I haven't > > tried.) > > Why would we need to inline anything if the partial unit is along side the > same compile units? Why wouldn't you just use DW_FORM_ref_addr to refer > directly to any DIEs in a partial unit from a compile unit?
DWZ also uses DW_FORM_ref_addr for exactly that. > I must be missing something. DWZ tries to keep the same structure of the DWARF files. If there is some top-level (under DW_TAG_compile_unit) declaration then it is kept there - by using DW_TAG_imported_unit. > I have the multiple files that refer to an external file with one or more > DW_TAG_partial_unit tags (or is there only ever just one > DW_TAG_partial_unit?). There are always many DW_TAG_partial_unit in both the DWZ-common symbol file and in the main symbol file. Only main symbol file contains many DW_TAG_compile_unit. > But I would like to see this inlined DW_TAG_partial_unit along side DWARF. You mean the real DWZ files? Here is some DWZ-compressed file: https://people.redhat.com/jkratoch/rustgdbbug.tar.xz main symbol file: rustgdbbug/a/b/rustdoc-1.24.0-2.fc27.x86_64.debug DWZ-common symbol file: rustgdbbug/.dwz/rust-1.24.0-2.fc27.x86_64 At least recent binutils readelf -wi decodes it correctly. > Why would and compile unit just not refer directly to the DIEs? They > shouldn't have to import anything? One cannot create new DIE under DW_TAG_compile_unit using just DW_FORM_ref_addr. That is what DW_TAG_imported_unit is good for. You are sort of right that one could move all declarations to a single DW_TAG_partial_unit and use one DW_TAG_imported_unit for that in each DW_TAG_compile_unit and it is done. But: (1) GDB would run out of memory when expanding any single CU. (2) Primitive types (and struct types in plain C) may differ between CUs. (3) It would make a subtle change of the DWARF structure causing various incompatibilities or even bugs in various tools (primarily GDB). > > One also needs to remap all the uses of DW_TAG_partial_unit, which is even > > used recursively (one DW_TAG_partial_unit uses DW_TAG_imported_unit for > > another DW_TAG_partial_unit etc.) otherwise there happen ambiguous > > lldb::user_id_t again. > > If this is all in the same file, then the offsets are all in the > .debug_info? What am I missing? LLVM was asserting when I reported the same lldb::user_id_t referenced by multiple CUs. From our discussion it looks to me that maybe I just did not have the DWZ common symbol file with proper offset. Otherwise maybe I can report the same lldb::user_id_t if multiple CUs reference the same DIE from DW_TAG_partial_unit? As LLVM considers all CUs in a file as the same context. I will try that again. Thanks, Jan _______________________________________________ lldb-commits mailing list firstname.lastname@example.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits