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
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
