This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]