From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Jim Blandy Cc: Daniel Berlin , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Add support for tracking/evaluating dwarf2 location expressions Date: Wed, 23 May 2001 08:51:00 -0000 Message-id: <87g0dw3w0c.fsf@dynamic-addr-83-177.resnet.rochester.edu> References: <87heye17ck.fsf@dynamic-addr-83-177.resnet.rochester.edu> <87n1852jnf.fsf@dynamic-addr-83-177.resnet.rochester.edu> X-SW-Source: 2001-05/msg00433.html Jim Blandy writes: > Daniel Berlin 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