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

[Daniel Berlin <dan at cgsoftware dot com>]

Jim Blandy <jimb@zwingli.cygnus.com> writes:

> 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.
Okey dokey.
But then agian, remember, the people who have control of the dwarf2
location expression definition are those who know what they need to be
able to represent, and be able to read. Namely, the compiler writers
and debugger writers.
That's all the dwarf2 committee is made up of. Compiler and debugger
vendors.  

However, if it helps make you feel we have more control over it, i'll
happily rewrite the location expression 
section of the dwarf2 doc, replacing DWARF2 with GDB, throw it in the
docs dir as a decription of our location expression format, and we can use
it as a starting point, and not be beholden to anyone at all, or even
feel the slightest twinge of guilt about adding/removing/changing
opcodes.



> 
> 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.

Okey, but the solution to this, IMHO, is to make the structures
opaque, and provide accessor routines, so that the only thing that can touch them is a few routines
in a file that knows the actual internal format, and how to do the
various ops we want to do (like adding a dereference to the top of the
stack, etc).

Then, we aren't dependent in the debug readers on the actual format
involved, and the only thing that is dependent on the format is the
actual evaluator for location expressions.


> 
> 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 believe the binding was introduced because of an assumption about
internal structure.  If you can't make these assumptions (attempts to
indirect through the opaque structure would give you compiler errors,
because it would have an incomplete type, or be a void *, or
something, depending on how you went about making it opaque), then you
are forced to do it the right way.

> 
> 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.

There is no such binding introduced, the expression evaluator language
has always been seperate, and will continue to be.  Unless you mean the symbol expression
evaluator we would be implementing, in which case, it would just use
the accessor functions itself to get the opcodes and arguments. By
doing this, the actual gdb internal representation could be different
from what the language says as well. The accessors would just
transform it on the fly to the language we have defined for the
symbol 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.

I don't think it should be *visible* that they are d2 location
expressions, to anything but a small number of routines that deal with
the internal gdb representation of a symbol location expression.  I'll
happily make the necessary accessors and opaque types and whatnot to
enforce this.



-- 
"There's a pizza place near where I live that sells only slices.
in the back you can see a guy tossing a triangle in the air.
"-Steven Wright