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