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

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

[Pierre Muller]

  Free Pascal compiler uses for
DW_AT_vtable_elem_location attribute a BLOCK consisting of
a DW_OP_constu marker followed by a unsigned_leb128 value
to indicate the offset within the virtual table of a virtual
function.
  GDB doesn't handle this currently, and this creates
errors in which attributes coming later, like
DW_AT_low_pc and DW_AT_high_pc not be set correctly
and thus generating lots of complaints.

  This patch allows to parse Free Pascal output correctly.
  
  Is this an acceptable patch?


Pierre Muller
Pascal language support maintainer for GDB

 
2010-05-12  Pierre Muller  <muller@ics.u-strasbg.fr>

	* dwarf2read.c (dwarf2_add_member_fn): Handle Free Pascal
	compiler method to give the offset of a virtual function
	in the virtual table.

Index: src/gdb/dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.383
diff -u -p -r1.383 dwarf2read.c
--- src/gdb/dwarf2read.c	8 May 2010 04:58:45 -0000	1.383
+++ src/gdb/dwarf2read.c	12 May 2010 12:51:20 -0000
@@ -4892,6 +4892,23 @@ dwarf2_add_member_fn (struct field_info 
 	  fnp->voffset += 2;
 	  fnp->fcontext = TYPE_TARGET_TYPE (TYPE_FIELD_TYPE (this_type, 0));
 	}
+      /* Support for Free Pascal description of virtual methods.  */
+      else if (attr_form_is_block (attr) && DW_BLOCK (attr)->size > 0
+	  && DW_BLOCK (attr)->data[0] == DW_OP_constu)
+	{
+	  struct dwarf_block blk;
+	  int num_read;
+
+	  blk.size = DW_BLOCK (attr)->size - 1;
+	  blk.data = DW_BLOCK (attr)->data + 1;
+	  fnp->voffset = read_unsigned_leb128 (NULL, (gdb_byte *) blk.data,
+					       &num_read);
+	  if (num_read > blk.size)
+	    dwarf2_invalid_attrib_class_complaint
("DW_AT_vtable_elem_location",
+						  fieldname);
+	  fnp->fcontext = TYPE_TARGET_TYPE (TYPE_FIELD_TYPE (this_type, 0));
+	}
+ 
       else
 	dwarf2_complex_location_expr_complaint ();
     }

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

[Tom Tromey]

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

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.

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

If it is not possible to fix the compiler, then I would propose making
this conditional on language_pascal.

If there is more to the expression, then maybe decode_locdesc already
handles it and we just need to update the gate in dwarf2_add_member_fn.

Tom

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

[Pierre Muller]

Tom, 
you have to take into account that
I know about nothing about DWARF :(

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Tom Tromey
> Envoyé : Wednesday, May 12, 2010 9:49 PM
> À : Pierre Muller
> Cc : gdb-patches@sourceware.org
> Objet : Re: [RFC] dwarf debug information: Handle Free Pascal virtual
> table indexes
> 
> >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>
> writes:
> 
> 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.
> 
> By my reading, this is incorrect DWARF.  Or is there more to the
> expression than that?

  What do you exactly mean by expression here?
 
> If it is not possible to fix the compiler, then I would propose making
> this conditional on language_pascal.
> 
> If there is more to the expression, then maybe decode_locdesc already
> handles it and we just need to update the gate in dwarf2_add_member_fn.

  I could indeed replace the call read_unsigned_leb128
by a call to decode_locdesc using DW_BLK(attr) but this
is still different from the other call to decode_locdesc 
earlier in the same function, because context is not set in Free Pascal
case.
 
  It is possible probably to fix the compile once
I understand clearly what is wrong...
But anyhow, this patch would allow released versions to be
read correctly.

Pierre

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

[Tom Tromey]

>>>>> "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