Re: supporting DW_OP_{implicit,stack}_value

[Roland McGrath <roland at redhat dot com>]

Let's take the two separately.  For the low-level stuff, DW_OP_stack_value
is trivial to support.  I added that.  What it means at higher level is
another story, but libdw per se so far doesn't do anything about that.
(So you could say it's just as trivial to support as DW_OP_piece...)

> -    DW_OP_implicit_value = 0x9e, /* DW_FORM_block follows opcode.  */
> +    DW_OP_implicit_value = 0x9e, /* ULEB128 size, followed by size bytes
> +				    in target memory representation.  */

Um.  So, that's what DW_FORM_block means.

The whole issue of the constant block being in target format is not new.
It's as it should be, and it's just the same as you already have for
e.g. DW_AT_const_value with a DW_FORM_block* (constant block) value.
As far as the semantics at that level go, the only innovation of
DW_OP_implicit_value is the combination of slicing via DW_OP_piece with a
constant block.

The thing that is new and that I don't like about DW_OP_implicit_value is
just the choice of using it for the low-level encoding.  (I had an
alternate proposal with equivalent semantics.)  The "innovation" there is
that all previous DWARF expression operations have 0..2 "stack word"
operands.  This led to the API based on Dwarf_Op, and that was quite dandy
as it was before DW_OP_implicit_value.  Now DW_OP_implicit_value comes
along with a different operand encoding than DWARF expressions ever used
before, and it does not fit at all well into what APIs we do have for
handling expressions.  But they've gone and done it, so we have to contort
to express it somehow.

My inclination is to make DW_OP_implicit_value a special case from the
libdw API perspective.  That is, the number/number2 fields will be
"internal form" rather than directly usable.  Then we give a call you can
pass such a Dwarf_Op to yield a Dwarf_Block.  

My inclination is to let this do some sanity-checking against bogus
Dwarf_Op's consed by callers, which means not just shoving pointers in
there.  Instead, it means the implicit_value->block call would take not
just the Dwarf_Op but also something like the Dwarf_Attribute that was used
to retrieve it.  With that, we could encode it as number=size,number2=secoff
where secoff is the offset into the .debug_{info,loc} section where the
data begins (i.e. after the size ULEB128).  From the Dwarf_Attribute's form
we can tell whether this op should refer to .debug_loc or .debug_info, and
then partially sanity-check the offset and size.

Conversely we could do something a little more magical.  The Dwarf_Op *
passed should always be one in the cache, and we can make that explicit in
the API.  So then it's easy to e.g. just store another lookup table indexed
by Dwarf_Op * storing the Dwarf_Block.  Then the Dwarf_Attribute passed to
the implicit_value->block call is really just used for its ->cu pointer.


Thanks,
Roland