This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]