Re: [RFC] dwarf debug information: Handle Free Pascal virtual table indexes

[Tom Tromey <tromey@redhat.com>]

>>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes:

Pierre> you have to take into account that
Pierre> I know about nothing about DWARF :(

No problem, don't worry about it :-)

Pierre> DW_AT_vtable_elem_location attribute a BLOCK consisting of
Pierre> a DW_OP_constu marker followed by a unsigned_leb128 value
Pierre> to indicate the offset within the virtual table of a virtual
Pierre> function.

Tom> By my reading, this is incorrect DWARF.  Or is there more to the
Tom> expression than that?

Pierre>   What do you exactly mean by expression here?
 
The value of DW_AT_vtable_elem_location is a DWARF location expression.
From the DWARF 4 (review) spec:

    An entry for a virtual function also has a DW_AT_vtable_elem_location
    attribute whose value contains a location description yielding the
    address of the slot for the function within the virtual function table
    for the enclosing class. The address of an object of the enclosing type
    is pushed onto the expression stack before the location description is
    evaluated.

One thing that would be helpful is if you ran "readelf -w" (or some
other DWARF dumper) on a program created by FPC that has this attribute,
then posted the DIE in question.

Also ... I forgot to mention this yesterday but I am curious to know how
gdb gets into an error state here.  My reading of the code in this area
is that gdb might issue a complaint, but it won't error out.  I would
expect it to ignore the attribute it can't recognize and continue on.

Pierre>   I could indeed replace the call read_unsigned_leb128
Pierre> by a call to decode_locdesc using DW_BLK(attr) but this
Pierre> is still different from the other call to decode_locdesc 
Pierre> earlier in the same function, because context is not set in Free Pascal
Pierre> case.
 
Is there some deep reason for this?  (I don't know.)
Offhand it looks reasonably safe to just set it.

I realize you may still need a pascal-specific case, since gdb doesn't
handle the full generality of DWARF in this area.  But if so, I think
this should be explicit.

Tom