[Dwarf-Discuss] PROPOSAL: DW_OP_entry_value

Jakub Jelinek jakub at redhat.com
Tue Aug 17 00:17:22 PDT 2010


The following proposal is something we've implemented as a vendor extension,
but before we actually deploy it we'd like to get some feedback on it here,
to minimize amount of divergence between the vendor extension and the
standard opcode if this gets accepted in some form into DWARF 5.  I'll
submit it formally through http://www.dwarfstd.org/Comment.php
eventually, incorporating possible feedback from this mailing list.

The extension has two main uses, one together with the extension I'll post
here momentarily, and for non-interactive debug info consumers which,
when they know beforehand that they will need to query a value equal
to a parameter value on entry to the function can put a breakpoint there
and remember that value there.

Tracking of values passed as arguments to functions in debug information


Many architectures pass arguments in registers and quite often
the register in which an argument has been passed is quickly reused
for something else. In that case all the debugger can say is that
a value has been optimized out.  If the argument is never modified
in the function, often the value can be discovered through extra
effort.  This could be by setting preemptive breakpoints to collect
argument values at function entry, or by unwinding in the debugger
to the caller and seeing what value has been passed to the function.
A companion proposal addresses unwinding to a caller to determine
argument values for such cases.

Proposed changes to DWARF

New DWARF expression operation

DW_OP_entry_value	0xa1	2	ULEB128 size followed by
					DWARF expression block
					of that size

Change "one special operation" into "two special operations".


2. DW_OP_entry_value

The DW_OP_entry_value operation pushes a value that had a known location
upon entering the current subprogram.  It uses two operands: an unsigned
LEB128 length, followed by a block containing a DWARF expression or
a simple register location description.  The length gives the length
in bytes of the block.  If the block contains a register location
description, DW_OP_entry_value pushes the value that register had upon
entering the current subprogram.  If the block contains a DWARF expression,
the DWARF expression is evaluated in a separate DWARF stack from the
currently used one as if it has been evaluated upon entering the current
subprogram.  The new DWARF stack is initially empty.  DW_OP_push_object_address
is not meaningful inside of this DWARF expression.  The DW_OP_entry_value
operation then pushes the value from the top of the new stack to the
previous stack, everything from the separate DWARF stack is afterwards


DW_OP_entry_value 1 DW_OP_reg5 DW_OP_stack_value
DW_OP_entry_value 2 DW_OP_breg5 0 DW_OP_stack_value

  Both of these location descriptions mean the value register 5 had upon
  entering of the current subprogram.

DW_OP_breg2 0 DW_OP_entry_value 1 DW_OP_reg5 DW_OP_add DW_OP_stack_value

  The value register 5 had upon entering of the current subprogram
  plus the value register 2 currently has.

DW_OP_entry_value 3 DW_OP_breg4 16 DW_OP_deref DW_OP_stack_value
DW_OP_entry_value 6 DW_OP_entry_value 1 DW_OP_reg4 DW_OP_plus_uconst 16 DW_OP_deref DW_OP_stack_value

  These two location expressions do the same thing, push the value
  memory location with size of an address pointed to by value of
  register 4 upon entering current subprogram plus 16 had upon 
  entering of the current subprogram.



DW_OP_entry_value	0xa1	2	ULEB128 size followed by
					DWARF expression block
					of that size

to figure 24.

Change History

Aug   11, 2010 - use 0xa1 instead of 0xa0, as 0xa0 is in
		 DW_OP_implicit_pointer proposal
May    4, 2010 - change DW_OP_entry_value argument to DWARF expression
		 from location description, add simple register location
		 description as more compact alternative (similar to
April 28, 2010 - the whole location expression in DW_OP_entry_value is
		 to be evaluated in the context upon entry of current
April 27, 2010 - split into separate DW_OP_entry_value and DW_TAG_call_site
April 26, 2010 - remove DW_AT_tail_call_count, add instead
April 15, 2010 - add optimized out parameters that aren't passed at all.
April 13, 2010 - initial draft.


More information about the Dwarf-Discuss mailing list