This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] Add support for tracking/evaluating dwarf2 location expressions
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