This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: supporting DW_OP_{implicit,stack}_value
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Thu, 10 Sep 2009 18:05:21 +0200
- Subject: Re: supporting DW_OP_{implicit,stack}_value
Hi Roland,
On Mon, 2009-07-20 at 12:12 -0700, Roland McGrath wrote:
> 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.
vta has landed now in gcc trunk and also is enabled in a backport for
fedora rawhide gcc. Have you thought about the above more? With
currently dwarf_getlocation_addr() will report DWARF_E_INVALID_DWARF
when it encounters a DW_OP_implicit_value. I hadn't noticed before
because I was still using my hacked up workaround locally that I posted
at the start of this thread.
Cheers,
Mark