Please submit proposals using the form at
http://dwarfstd.org/Comment.php.
Thanks!
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>
--
Michael Eager eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077