[Dwarf-Discuss] PROPOSAL: DW_OP_implicit_pointer

[Ron Brender]

Roland,

In reviewing the proposal I feel unclear regarding what problem it is 
intended to solve.

If I understand correctly, the effect of this operator is equivalent to 
replicating the DW_AT_location or DW_AT_const_value of the referenced 
DIE followed by an DW_OP_add operation using the second parameter. Is 
this a correct understanding.

If so, it appears that the primary intended benefit is a space saving by 
avoiding replication of potentially large _location or _const_value 
attributes.

If I have got it all wrong, please clarify.

Thanks,
Ron

---------------------
Roland McGrath wrote:
> This is a proposal and request for comments on a new location expression
> feature for a future version of DWARF, called DW_OP_implicit_pointer.
> Details are below the fold.
> 
> We have an implementation today of this as a vendor extension using an
> opcode in the DW_OP_lo_user+ range, DW_OP_GNU_implicit_pointer (0xf2).
> We have an experimental implementation of the producer side for gcc, and
> of the consumer side for systemtap/elfutils.  
> 
> We intend to start deploying this quite soon.  If discussion here
> reaches a different consensus on how to specify and encode this idea
> concretely in DWARF, then we will adapt our vendor extension to match
> the new consensus plan.  Otherwise, we will go ahead with this as we
> have specified it here, with hopes that a future DWARF standard will
> specify something that closely matches what we're using (just with
> opcodes in the standard range).
> 
> I don't know if there is any schedule or roadmap for revisions of DWARF
> after version 4.  Since version 4 was just finalized, I imagine it could
> be years away.  By then, whatever vendor extension we settle on now will
> have become wide-spread existing practice with a very common producer.
> 
> 
> Thanks,
> Roland
> 
> Implicit pointer values in debug information
> ============================================
> 
> Overview
> --------
> 
> Optimized compilation can eliminate a pointer that exists in the
> semantics of the source program (including C++ "references" and other
> source language constructs with pointer-like semantics).  These may be
> pointer-typed variables, or portions of aggregate data structures that
> are ordinarily represented as address values.  While no actual address
> will ever exist for these semantic pointers at runtime, often what they
> "point to" has a known location in registers or discontiguous pieces, or
> can be rematerialized from other information at runtime.
> 
> For example, consider the C function:
> 
> 	static void add_point (struct point *a, const struct point *b)
> 	{
> 	  a->x += b->x;
> 	  a->y += b->y;
> 	}
> 
> This may be inlined away in compilation such that all the members of the
> two structures exist only in registers.  A debugger cannot show the user
> an address value for "a" or "b", but it can show a struct value for "*a"
> or "*b", and it can evaluate "a->x" or "b->y".  Another common example
> is the "this" pointers and reference-typed arguments in C++ methods
> handling class types with small amounts of data so they are inlined away
> into using just registers.  More complex examples can include pointers
> into the middle of an array or other aggregate type, optimized-away
> aggregates containing pointer-typed members, pointers to constants
> optimized away, multiple levels of pointer indirection optimized away,
> and combinations of all these.
> 
> 
> Proposed changes to DWARF
> -------------------------
> 
> New location expression operation (7.7.1, Figure 24):
> 
> DW_OP_implicit_pointer		0xa0	2	4- or 8-byte offset of DIE
> 						followed by SLEB128 offset
> [Note: The current vendor extension is DW_OP_GNU_implicit_pointer, code 0xf2.]
> 
> 2.6.1.1.3
> Add to the enumerated list:
> 
> 3. DW_OP_implicit_pointer
> 
>    The DW_OP_implicit_pointer operation has two operands: a debugging
>    information entry reference (as for DW_OP_call_ref), followed by a
>    signed LEB128 offset.  It specifies an object that has the semantics
>    of a target memory address, but that neither has any actual location
>    itself nor has the value of any actual memory address.  Instead, it
>    refers to an imaginary address inside another object.  The second
>    operand gives the offset in bytes from the beginning of that other
>    object where this imaginary address points.  The debugging
>    information entry indicated by the first operand has either a
>    DW_AT_location attribute or DW_AT_const_value attribute.  The
>    semantic operations of arithmetic on the implicit pointer create
>    implicit pointer values with different byte offsets relative to that
>    object as it would appear in the target memory representation.  The
>    semantic operation of dereferencing the implicit pointer leads to
>    that location or value.
> 
>    There is no inherent semantics implied by the debugging information
>    entry reference used in a DW_OP_implicit_pointer operation.  It serves
>    only as a means to find a DW_AT_location or DW_AT_const_value attribute
>    that is interpreted as described above.  If there is no program entity
>    with an entry to refer to, a DW_TAG_dwarf_procedure entry can be created
>    just for this purpose.
> 
> 7.4, paragraph 3:
> 
> Add
> 	DW_OP_implicit_pointer	offset in .debug_info
> into the table.
> 
> Appendix B, Figure 43:
> 
> Add DW_OP_implicit_pointer alongside DW_OP_call_ref.
> 
> Appendix B, in note (e) after Figure 43, after "the DW_OP_call_ref DWARF
> expression operator", add "and the first operand of the
> DW_OP_implicit_pointer DWARF location expression operator".
> 
> Change History
> --------------
> 
> Aug 3, 2010 - Mention DW_OP_GNU_implicit_pointer value now in use.
> May 28, 2010 - Mention DW_TAG_dwarf_procedure use.  Correct cross-references.
> May 27, 2010 - initial draft.
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
> 
>