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

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

Daniel Berlin <dan@cgsoftware.com> writes:
> 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.

Yes, that's a step in the right direction.

I don't think it matters whether the representation is opaque or not.
Opacity has its price --- opacity can cause obscurity.

What's important is for the code to take an explicit step to translate
all debug info location information (including Dwarf 2 location
expressions) into the internal form.  The code must not assume that,
say, for Dwarf 2, the translation into internal form is trivial.

One way to enforce this would be to take the opportunity to simplify
the language a little bit.  For example, I don't think we need
forty-two different opcodes for pushing constants (DW_OP_lit*,
DW_OP_addr, DW_OP_const*); I don't think we need the compound opcodes
like DW_OP_breg*, DW_OP_plus_uconst; and so on.  And pushing constants
out into an array on the side of the bytecode stream, with a bytecode
to fetch constants by index, would allow us to bcache bytecode strings
more effectively --- everyone whose location is a constant offset from
a register, say, could share a single bytecode string.

This would have the side effect (which may seem like make-work, but I
think is actually a good thing) of preventing people from just dumping
blocks of Dwarf2 locexpr bytecode into GDB's internals --- creating
the sort of binding we're trying to avoid.