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.