||Interaction of DW_OP_piece (and similar) and DW_OP_call2 (and similar)
Section 2.6, pg various
The specification does not say much about how the concept of pieces interact
with the ability of a DWARF expression to encode "calls".
The only thing it does say that seems possibly definitive is in 2.6.1:
"Each simple location description that is a DWARF expression is evaluated
independently of any others."
Which would suggest that the intended meaning of a "piece" op is to mark
the boundaries between completely separate expressions that do not share
a stack at all. Under this interpretation implementations would be able
to decode the opcode stream once to mark the ranges of each simple location
within the composite location and then handle them independently. Further
under this interpretation a "piece" op in a "call" would be illegal, as
that would imply that a call from a DWARF expression calls into a compound
location, and the spec claims that a "call" op is transferring control at
the level of DWARF expressions.
(18.104.22.168 "These operations transfer control of DWARF expression evaluation ...")
This would be great, but the problem is that in practice this doesn't seem
to be how it's being used.
Looking just at GDB:
/* Record the piece. */
op_ptr = read_uleb128 (op_ptr, op_end, &size);
add_piece (ctx, 8 * size, 0);
/* Pop off the address/regnum, and reset the location
if (ctx->location != DWARF_VALUE_LITERAL
&& ctx->location != DWARF_VALUE_OPTIMIZED_OUT)
ctx->location = DWARF_VALUE_MEMORY;
Here the interpretation of the "piece" op is just to pop one value from the
stack, not to fully reset the stack. Under this interpretation a composite
location has been treated as the same thing as a DWARF expression. Callees
can emit pieces into the same composite location as callers, and the "simple
location" after the first "piece" op is not necessarily isolated from the
work that was done in first "simple location".