[Lldb-commits] [PATCH] D45170: Cleanup DWARFCompileUnit and DWARFUnit in preparation for adding DWARFTypeUnit

[Jan Kratochvil via lldb-commits]

On Wed, 11 Apr 2018 00:22:45 +0200, Greg Clayton wrote:
> > On Apr 10, 2018, at 2:38 PM, Jan Kratochvil <jan.kratochvil at 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