[Dwarf-Discuss] PROPOSAL: DW_OP_implicit_pointer
ron.brender at charter.net
Thu Aug 12 06:54:40 PDT 2010
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
If I have got it all wrong, please clarify.
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.
> Implicit pointer values in debug information
> 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.]
> 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:
> 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
More information about the Dwarf-Discuss