RE: DWARF3 DW_OP_push_object_address - requirement for deferred evaluation?

["Gary Funck" <gary@intrepid.com>]

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?