[Dwarf-Discuss] PROPOSAL: DW_OP_implicit_pointer

[Roland McGrath]

> OK, good, that helps a lot. One can imagine that the internal debug 
> implementation can use a kind of "unavailable but potentially unneeded 
> pointer" value that is not, of itself, necessarily a user error until 
> that turns out to be the value of the overall user expression.

That's exactly what we do...we call it an "implicit pointer" value.  Note
that you can add and subtract integer offsets from an implicit pointer, as
well as just pass an original implicit pointer around.  It's only when you
want to dereference the pointer that you check that its offset portion
falls inside an accessible object of some kind.  

> Now keep going... How does DW_op_implicit_pointer help with 
> disaggregated fields of a struct?

When the implicit pointer points to an object with a composite location
description, then the offset (and the size of the field you want) tells you
which piece(s) contain the datum you want.

The way you handle the offset component of an implicit pointer when
dereferencing is the same as applying a DW_AT_data_member_location offset
(i.e. an integer value for that attribute, or an expression equivalent to
DW_OP_plus_uconst, which is the norm) to any location description.  When
that's a memory location description, it's literally arithmetic.  In all
other cases (enumerated in 2.6.1), you have to do some "virtual offsetting"
in an imaginary memory address space in the mind of the debugger.

The only parts of this that are at all new are representing an implicit
pointer to begin with, doing arithmetic (i.e. offset adjustments) on it,
and dereferencing the implicit pointer.  On the other side of that
dereference, everything is as it already is.


Thanks,
Roland