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

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

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

[Jonas Maebe]

On 13 May 2010, at 19:17, Tom Tromey wrote:

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

I agree with you that from reading the DWARF spec it seems that we are generating an incomplete location. Here's a dwarfdump of what we generate (Mac OS X):

0x000000f1:         TAG_subprogram [12] *
                     AT_name( "TEST" )
                     AT_prototyped( 0x01 )
                     AT_calling_convention( 0x41 )
                     AT_external( 0x01 )
                     AT_virtuality( DW_VIRTUALITY_virtual )
                     AT_vtable_elem_location( <0x2> 10 03  )
                     AT_low_pc( 0x00000050 )
                     AT_high_pc( 0x00000096 )

I based that on what I saw gcc 4.0 (and 4.2) generate under Mac OS X for a virtual C++ method:

0x00007d35:         TAG_subprogram [115] *
                     AT_external( 0x01 )
                     AT_name( "eat" )
                     AT_decl_file( "/Volumes/Leopard/Data/dev/fpc/test/virtmeth.cpp" )
                     AT_decl_line( 7 )
                     AT_MIPS_linkage_name( "_ZN6Animal3eatEv" )
                     AT_virtuality( DW_VIRTUALITY_virtual )
                     AT_vtable_elem_location( <0x2> 10 00  )
                     AT_containing_type( {0x00007d0f} )
                     AT_declaration( 0x01 )
                     AT_sibling( {0x00007d55} )

In fact, it seem to be the same for g++ 4.1.2 under Linux/x86-64:

 <2><5ce5>: Abbrev Number: 102 (DW_TAG_subprogram)
     DW_AT_external    : 1      
     DW_AT_name        : eat    
     DW_AT_decl_file   : 1      
     DW_AT_decl_line   : 7      
     DW_AT_MIPS_linkage_name: _ZN6Animal3eatEv  
     DW_AT_virtuality  : 1      (virtual)
     DW_AT_vtable_elem_location: 2 byte block: 10 0     (DW_OP_constu: 0)
     DW_AT_containing_type: <5c94>      
     DW_AT_declaration : 1      

So I'm not sure what's going on here. The C++ code I used is below (some example I took from the web).


Jonas

#include <iostream>
using namespace std;
 
class Animal
{
public:
   virtual void eat() { cout << "I eat like a generic Animal." << endl; 
}
};
 
class Wolf : public Animal
{
public:
   void eat() { cout << "I eat like a wolf!" << endl; }
};
 
class Fish : public Animal
{
public:
   void eat() { cout << "I eat like a fish!" << endl; }
};
 
class OtherAnimal : public Animal
{
};
 
int main()
{
   Animal* anAnimal[4];
 
   anAnimal[0] = new Animal();
   anAnimal[1] = new Wolf();
   anAnimal[2] = new Fish();
   anAnimal[3] = new OtherAnimal();
 
   for (int i = 0; i < 4; i++) {
      anAnimal[i]->eat();
      delete anAnimal[i];
  }
 
   return 0;
}

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

[Tom Tromey]

>>>>> "Jonas" == Jonas Maebe <jonas.maebe@elis.ugent.be> writes:

Jonas> I based that on what I saw gcc 4.0 (and 4.2) generate under Mac
Jonas> OS X for a virtual C++ method:

Thanks for pointing this out.  It turns out that g++ is also doing the
wrong thing.  I filed this today after asking Jason about it:

    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44126

So I guess we can safely try to reuse the existing C++ branch in the
DWARF reader for the Pascal case.  Whatever we have to do to support a
fixed g++ will have to work in a backward-compatible way anyhow.

Tom

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

[Jonas Maebe]

On 13 May 2010, at 22:53, Tom Tromey wrote:

>>>>>> "Jonas" == Jonas Maebe <jonas.maebe@elis.ugent.be> writes:
> 
> Jonas> I based that on what I saw gcc 4.0 (and 4.2) generate under Mac
> Jonas> OS X for a virtual C++ method:
> 
> Thanks for pointing this out.  It turns out that g++ is also doing the
> wrong thing.  I filed this today after asking Jason about it:
> 
>    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44126
> 
> So I guess we can safely try to reuse the existing C++ branch in the
> DWARF reader for the Pascal case.

I agree. And I assume it is currently not used because we don't generate an AT_containing_type attribute (because that's used by GDB's DWARF parser to initialise fnp->fcontext). That should not be too difficult to add, but I'm not sure what it's doing in the debug info as part of a TAG_subprogram.

As far as I can see, it's only defined by the DWARF3 spec for DW_TAG_ptr_to_member_type entries (which are not supported by GDB, and I'm not entirely sure about what their purpose is). Both GCC and FPC put all method declarations as childs of the containing type's TAG_structure_type, so I think that the context is implicit anyway.


Jonas

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

[Tom Tromey]

>>>>> "Jonas" == Jonas Maebe <jonas.maebe@elis.ugent.be> writes:

>> So I guess we can safely try to reuse the existing C++ branch in the
>> DWARF reader for the Pascal case.

Jonas> I agree. And I assume it is currently not used because we don't
Jonas> generate an AT_containing_type attribute (because that's used by
Jonas> GDB's DWARF parser to initialise fnp->fcontext). That should not
Jonas> be too difficult to add, but I'm not sure what it's doing in the
Jonas> debug info as part of a TAG_subprogram.

I misread the code a little yesterday -- I didn't notice that the
existing code is stripping an initial DW_OP_ref.  So I think if FPC
emitted correct DWARF, gdb would already handle it.  Well, maybe
... there is a "fnp->voffset += 2" in there that I don't understand the
rationale for.

The AT_containing_type stuff seems to be some historical relic in gcc.
The reason it is important now is that it is the way gdb recognizes that
it should use a gcc-specific hack.

Jonas> As far as I can see, it's only defined by the DWARF3 spec for
Jonas> DW_TAG_ptr_to_member_type entries (which are not supported by
Jonas> GDB, and I'm not entirely sure about what their purpose is).

They are for the C++ pointer-to-member feature.  GDB doesn't implement
these because GCC doesn't emit them, preferring instead another
GCC-specific hack :-(.  There is a PR in GCC bugzilla for this too.

Tom