support for DWARF3 operations?

support for DWARF3 operations?

[Gary Funck]

I may have a need to use DW_OP_push_object_address,
described here:
http://www.eagercon.com/dwarf/issues/991108-11.htm
and more definitively here:
http://www.eagercon.com/dwarf/dwarf3std.htm

Has any work been done in GDB to support some or all
of the DWARF3 functionality?

thanks - Gary

Re: support for DWARF3 operations?

[Daniel Jacobowitz]

On Tue, Mar 06, 2007 at 07:49:02AM -0800, Gary Funck wrote:
> 
> I may have a need to use DW_OP_push_object_address,
> described here:
> http://www.eagercon.com/dwarf/issues/991108-11.htm
> and more definitively here:
> http://www.eagercon.com/dwarf/dwarf3std.htm
> 
> Has any work been done in GDB to support some or all
> of the DWARF3 functionality?

Yes - some, but not that particular bit.  It should not be at all
hard.  It's a bit complicated by the fact that GDB sometimes
implicitly pushes the object address, though.

-- 
Daniel Jacobowitz
CodeSourcery

DWARF3 DW_OP_push_object_address - requirement for deferred evaluation?

[Gary Funck]

Daniel Jacobowitz replied:
> On Tue, Mar 06, 2007 at 07:49:02AM -0800, Gary Funck wrote:
> > I may have a need to use DW_OP_push_object_address.
> > Has any work been done in GDB to support some or all
> > of the DWARF3 functionality?
> 
> Yes - some, but not that particular bit [support for
DW_OP_push_object_address].  > It should not be at all hard.  It's a bit
complicated by the fact
> that GDB sometimes implicitly pushes the object address, though.

Is  decode_locdesc() (in dwarf2read.c) the only routine that
evaluates location descriptions?

Would you please elaborate on your statement that "GDB sometimes
implicitly pushes the object address"?

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?

If this is the case, it didn't appear to me that GDB currently has
a mechanism for delaying the binding of address information
that is required to reference a variable.  Or perhaps I missed
something?

RE: DWARF3 DW_OP_push_object_address - requirement for deferred evaluation?

[Gary Funck]

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?

Re: DWARF3 DW_OP_push_object_address - requirement for deferred evaluation?

[Daniel Jacobowitz]

On Tue, Mar 06, 2007 at 04:11:29PM -0800, Gary Funck wrote:
> 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?

No, it's an entirely different sort of problem.  I think you'll be in
some difficulty with globals with computed addresses, though I'm not
sure how that would arise needing DW_OP_push_object_address.
Normally, it only occurs today for local variables...

I think there is some case where we evaluate simple location
descriptions relative to the object address, but shouldn't.  However,
I do not remember the details.

-- 
Daniel Jacobowitz
CodeSourcery

RE: support for DWARF3 operations?

[Gary Funck]

 

> I may have a need to use DW_OP_push_object_address,
> described here:
> http://www.eagercon.com/dwarf/issues/991108-11.htm
> and more definitively here:
> http://www.eagercon.com/dwarf/dwarf3std.htm

FYI.  The DWARF3 standard seems to have moved
to here: http://www.dwarfstd.org/Dwarf3.pdf