[Bug gdb/20426] gdb does not interpret DWARF annotating imported units fully

["mjw at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20426

--- Comment #1 from Mark Wielaard <mjw at redhat dot com> ---
I admit to not know anything about how gdb implements this. But looking at the
DIE tree I think it is not surprising the location of the upper_bound cannot be
found.

In other DWARF consumers I have worked with following the specification or
abstract origin attribute is used to augment the current DIE under
consideration, not the other way around. To make it work the other way around a
DWARF consumer would have to keep track of all references through
DW_AT_specification or DW_AT_abstract_origin to a specific DIE.

In this case what a DWARF consumer probably would do is find the the subprogram
[b6] based on the address (main function) that it covers. If the user wants to
inspect the variable "a" it will find [e7] (with the name given through the
DW_AT_specification to [43]). Now this variable DIE [e7] will then be passed to
some function to resolve it (find the location expression). Given such a
variable DIE is normally enough to resolve all relevant location information.
In this case it points to the array_type [79] and finally the upper_bound,
which points to the variable described at [3e]. Following the DIE reference
chain there is nothing indicating that the missing location expression for that
variable can be found through the [df] DIE in the other compilation unit.

It is not immediately clear to me which heuristic needs to be used to deduce
that the [df] DIE specification attribute pointing to [e3] needs to be
remembered as back reference (assuming it has even has been seen yet by DWARF
reader, if the variable and formal_parameter were in a different order in the
tree we might not even have seen it yet). Or how the consumer can be sure it
has seen and collected all such back-references needed (assuming we do want the
DWARF consumer to be as efficient as possible by reading as little of the DIE
tree as possible).

-- 
You are receiving this mail because:
You are on the CC list for the bug.