This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: DWARF3 DW_OP_push_object_address - requirement for deferred evaluation?
- From: "Gary Funck" <gary at intrepid dot com>
- To: <gdb at sourceware dot org>
- Date: Tue, 6 Mar 2007 16:11:29 -0800
- Subject: RE: DWARF3 DW_OP_push_object_address - requirement for deferred evaluation?
Gary Funck wrote:
> Given that DW_OP_push_object_address was introduced in DWARF3 to
> provide support for objects and data that are described by
> "dope vectors", for which their address and other characteristics
> such as array bounds are not known until runtime .... is the case
> that the evaluation of a descriptor utilizing
> DW_OP_push_object_address
> must be deferred until either the referenced object is instantiated,
> or the GDB user makes reference to the object?
Scratch this question. I see where dwarf2_symbol_mark_computed(),
var_decode_location() calls dwarf2_symbol_mark_computed() which
copies the location description into the symbol table entry and
marks the location as LOC_COMPUTED.
Still, I was a bit confused by the code in add_partial_symbol(), which
checks to see if the symbol is external, and in that case seems to
assume that the location description is "simple" and can be computed
by decode_locdesc(), which evaluates to a fixed CORE_ADDR. If this
global variable in fact is allocated at runtime and its data and
size are described by a dope vector, then this assumption will not
hold? Is this one of those places that you were referring to
when you said that GDB sometimes pushes the object's address?