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

[Daniel Berlin <dan@cgsoftware.com>]

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

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

Funny you mention, I had just done the first of these (removing a lot
of space saving opcodes) last night.

It's when I noticed we can't properly pass LONGEST values (long long
int on my powerbook) through vararg functions.


> 
> 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.
It's not possible anyway.
The opcode numbers are different already


The enum used to look like:

enum dwarf_location_atom
{
        DW_OP_addr = 0x3f,
        DW_OP_xxx = 0x49,
        DW_OP_yyy = 0x42,
}
etc
It now looks like
enum locexpr_opcode
{
        GLO_addr,
        GLO_xxx,
        GLO_yyy
}



-- 
"My girlfriend does her nails with white-out.  When she's asleep,
I go over there and write misspelled words on them.
"-Steven Wright