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

[Jim Blandy <jimb@zwingli.cygnus.com>]

Daniel Berlin <dan@cgsoftware.com> writes:
> However, IMHO, the location expression language that dwarf2 uses is
> self-contained, and suited for GDB's needs. Perfectly in fact. It
> provides no more or less than necessary to describe our locations,
> except where it saved a little space in real use (see below) and
> it's trivial to convert other expression languages into it. and The
> location list is simply a list of ranges and location expressions,
> which is what we would have come up with anyway, judging from GDB structures.
> 
> In fact, I'd wager if we tried, we'd come up with something almost
> exactly like d2 location expressions:
> 
> We would want some kind of simple, stack based language.
> Normal binary and unary arithmetic operations, and normal stack
> operations (rotate, pop, drop, etc).
> Past these, we'd want a way of:
> dereferencing the value on top of the stack as if it was a memory address.
> A way to load constant values onto the stack
> A way to load register values onto the stack
> An efficient encoding, able to handle differing sizes for data types
> on different platforms.

Yes, you're right --- what we'd come up with would be very similar to
Dwarf 2 location expressions.

> Why bother not just using something we already have a standard for,
> if it's going to 99.9% the same?

There's nothing technically wrong with using Dwarf 2 location
expressions and location lists internally in GDB.  We could do a
perfectly correct implementation that would work fine.  When I say
`self-contained', I'm not talking about the implementation; I'm more
concerned with modularity, and who has control of the definition.

I'm not sure how to put this convincingly.  Let me try to draw an
analogy with another problematic area.  GDB stores the machine's
registers as a big block of bytes.  The layout of GDB's register file
is the same as the layout of the 'G' packet.  While there's nothing
technically wrong with this, it's ended up being a technical
nightmare, because whenever we want to do something reasonable with
GDB's internal register file, we have to worry about the remote
protocol.

Using a common structure there simplified the remote protocol code,
but it also introduced a binding (in the mechanical sense, of things
rubbing against each other in a way that prevents the machine from
operating smoothly) between the remote protocol and GDB's internals
that has been a pain in the neck.

I don't want to introduce this sort of binding between GDB's debug
readers and its expression evaluator, by requiring that they use the
same representation for location expressions.

I admit that this is a very touchy-feely argument.  If the other
maintainers don't share my sense of unease with using Dwarf 2 location
expressions directly in GDB, then I'll drop the objection.