Re: [PATCH] Add support for tracking/evaluating dwarf2 location expressions

[Jim Blandy <jimb at zwingli dot cygnus dot com>]

Daniel Berlin <dberlin@redhat.com> writes:
> This patch adds a place in the symbol structure to store the dwarf2
> location (an upcoming dwarf2read huge rewrite patch uses it), an
> evaluation maachine to findvar.c, and has read_var_value use the dwarf2
> location if it's available.

I think this is the wrong approach to the right idea.

I think it would be a great idea to give GDB more powerful ways to
describe the locations of variables, structure fields, and so on.
This would be a clean alternative to including special-purpose,
ABI-specific logic in GDB.

For example, one of the nice properties of the way GDB's `struct type'
represents a structure type in the present code is that it's mostly
ABI-independent.  Since the debug info spells out the exact position
of each structure member, GDB doesn't have to know the ABI's structure
layout rules, alignment requirements, and so on.

However, if we want to support virtual base classes, it's not clear
how to extend that structure appropriately.  In the V2 C++ ABI, each
object contained pointers to its virtual bases.  In the V3 C++ ABI, an
object's virtual table provides offsets to its virtual bases.  At the
moment, our `solution' is to provide ABI-specific code to find your
virtual bases.

If GDB supported a fully general location expression language, like
Dwarf 2 location expressions, then `struct type' could simply provide
a location expression to find each member or base class of the object.
In most cases, these location expressions would be trivial, but we
could easily encode both the V2 and V3 C++ ABI behaviors in this
manner.  It would then become the compiler's responsibility to
describe the ABI it was using.  We could take a similar approach to
finding virtual functions.


That said, I think the core of GDB should be independent of the
debugging information format.  If GDB does adopt a fully general
location expression language, then it should have a self-contained
description, which can be designed to suit GDB's needs.  Then we can
translate Dwarf2 expressions into that form.