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 11:53:00 -0000 Message-id: <87wv77zym7.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/msg00441.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. 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