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

Here is how the language currently stands (this is actually symeval.h pasted): 

#ifndef SYMEVAL_H
#define SYMEVAL_H

enum locexpr_opcode
  {
    GLO_addr,
    GLO_deref,
    GLO_constu,
    GLO_consts,
    GLO_dup,
    GLO_drop,
    GLO_over,
    GLO_pick,
    GLO_swap,
    GLO_rot,
    GLO_xderef,
    GLO_abs,
    GLO_and,
    GLO_div,
    GLO_minus,
    GLO_mod,
    GLO_mul,
    GLO_neg,
    GLO_not,
    GLO_or,
    GLO_plus,
    GLO_shl,
    GLO_shr,
    GLO_shra,
    GLO_xor,
    GLO_bra,
    GLO_eq,
    GLO_ge,
    GLO_gt,
    GLO_le,
    GLO_lt,
    GLO_ne,
    GLO_skip,
    GLO_regx,
    GLO_fbreg,
    GLO_bregx,
    GLO_piece,
    GLO_deref_size,
    GLO_xderef_size
  };


void init_locexpr (locexpr *);
void destroy_locexpr (locexpr *);
void locexpr_push_op  (locexpr, enum locexpr_opcode, const char *, ...);
void locexpr_get_op (locexpr, unsigned int,  enum locexpr_opcode *);
void locexpr_get_longest (locexpr, unsigned int, LONGEST *);
void locexpr_get_ulongest (locexpr, unsigned int, ULONGEST *);
void locexpr_get_uchar (locexpr, unsigned int, unsigned char *);
value_ptr evaluate_locexpr (struct symbol *, struct frame_info *, locexpr, struct type *);
#endif

I kept bregx only because we already have a location type for based
registers, so it seemed to make sense (Admittedly, all it does is take
us from two opcodes to one for this).

fbreg we can't get rid of, we don't necessarily know the frame
register at debug reading time (it may itself be using a location list
to say where it is).

xderef we can't get rid of, we have architectures with multiple
address spaces, so it'll be necessary for them.

the *_size we can't get rid of, because we frequently only want a
certain number of bytes of a pointer.

We could get rid of the "default" opcodes deref and xderef, and just
always use xderef_size and deref_size with an explicit size.

I think other than that, i've gotten rid of all of the unneeded
opcodes.

If everyone agrees, i'll write up the docs on these opcodes, and the
functions to manipulate location expressions.

It currently has no dependencies on anything at all, so i can submit
the symeval.[ch] files, and the symtab.h change to add locexpr to the
symbol struct (and to the location types enum) , without affecting
anything else.

Eventually, I'll get rid of all the other location types, but this can
be done incrementally, so it's no rush at all.

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

-- 
"I was watching the Superbowl with my 92 year old grandfather.
The team scored a touchdown.  They showed the instant replay.
He thought they scored another one.  I was gonna tell him, but I
figured the game *he* was watching was better.
"-Steven Wright