C++ debugging progress

C++ debugging progress

[Daniel Jacobowitz]

For the curious, I've gotten all but two of the virtual function tests to
pass in virtfuncs.exp.  I'm not entirely sure what's wrong with one of the
others, and the other goes up as far as the parser (pEe->D::fd() yields
"attempt to take address of value not in memory").  There's also a bunch of
namespace problems, of course.

I'll not be posting the patches for another day or two.  The way I do it now
is grossly inefficient; I look through RTTI at every lookup instead of once
per type.  It also depends on presence of RTTI.  There's not much I can do
about that - or rather, I could, but AFAICT it would require walking the
inheritance graph in the proper order and I don't have the machinery to do
that easily.  I'm not heartbroken that we need RTTI for debugging though.

So once I clean them up a little I'll post the rest for people to try.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

C++ debugging progress

[Daniel Jacobowitz]

For the curious, I've gotten all but two of the virtual function tests to
pass in virtfuncs.exp.  I'm not entirely sure what's wrong with one of the
others, and the other goes up as far as the parser (pEe->D::fd() yields
"attempt to take address of value not in memory").  There's also a bunch of
namespace problems, of course.

I'll not be posting the patches for another day or two.  The way I do it now
is grossly inefficient; I look through RTTI at every lookup instead of once
per type.  It also depends on presence of RTTI.  There's not much I can do
about that - or rather, I could, but AFAICT it would require walking the
inheritance graph in the proper order and I don't have the machinery to do
that easily.  I'm not heartbroken that we need RTTI for debugging though.

So once I clean them up a little I'll post the rest for people to try.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: C++ debugging progress

[Benjamin Kosnik]

> For the curious, I've gotten all but two of the virtual function tests to
> pass in virtfuncs.exp.  I'm not entirely sure what's wrong with one of the
> others, and the other goes up as far as the parser (pEe->D::fd() yields
> "attempt to take address of value not in memory").  There's also a bunch of
> namespace problems, of course.

Yay. 

> So once I clean them up a little I'll post the rest for people to try.

Please do! I'm looking forward to it.

Thanks,
benjamin

Re: C++ debugging progress

[Benjamin Kosnik]

> For the curious, I've gotten all but two of the virtual function tests to
> pass in virtfuncs.exp.  I'm not entirely sure what's wrong with one of the
> others, and the other goes up as far as the parser (pEe->D::fd() yields
> "attempt to take address of value not in memory").  There's also a bunch of
> namespace problems, of course.

Yay. 

> So once I clean them up a little I'll post the rest for people to try.

Please do! I'm looking forward to it.

Thanks,
benjamin

Re: C++ debugging progress

[Daniel Berlin]

On Wed, 28 Nov 2001, Daniel Jacobowitz wrote:

> For the curious, I've gotten all but two of the virtual function tests to
> pass in virtfuncs.exp.  I'm not entirely sure what's wrong with one of the
> others, and the other goes up as far as the parser (pEe->D::fd() yields
> "attempt to take address of value not in memory").  There's also a bunch of
> namespace problems, of course.
>
> I'll not be posting the patches for another day or two.  The way I do it now
> is grossly inefficient; I look through RTTI at every lookup instead of once
> per type.  It also depends on presence of RTTI.  There's not much I can do
> about that - or rather, I could, but AFAICT it would require walking the
> inheritance graph in the proper order and I don't have the machinery to do
> that easily.  I'm not heartbroken that we need RTTI for debugging though.

Nor am I.
However:
     * To: gdb-patches at sources dot redhat dot com
     * Subject: Re: Using typeinfo functions to determine RTTI
     * From: Tom Tromey <tromey at cygnus dot com>
     * Date: 03 May 2000 09:41:50 -0600
     * Newsgroups: cygnus.patches.gdb
     * Organization: Cygnus Solutions
     * References:
<Pine.LNX.4.10.10005020923450.14281-100000@propylaea.anduin.com>
<npu2ggf8g3.fsf@zwingli.cygnus.com>
     * Reply-To: tromey at cygnus dot com
 (This was me):
 >> Does anyone mind if i use the typeinfo name, rather than
 >> the virtual table name, to figure out th real type of an object? It
 >> only matters if someone does -fno-rtti, i believe. But I have no
 >> idea how many people actually use that flag to save time/space in
 >> debugging executables.

 Jim> Almost all of Cygnus's customers use GDB to debug embedded apps,
 Jim> and space is often an issue there.  But I don't actually know how
 Jim> many of them use -fno-rtti.

 All Java programs are compiled with -fno-rtti.  This includes the C++
 component.  So presumably if this change is made it will make it even
 harder for me to debug libgcj.

 Tom

Re: C++ debugging progress

[Dan Mosedale]

Daniel Berlin wrote:

> Subject:
>
> Re: C++ debugging progress
> From:
>
> Daniel Berlin <dan@cgsoftware.com>
> Date:
>
> Wed, 28 Nov 2001 02:43:43 -0500 (EST)
>
> To:
>
> Daniel Jacobowitz <drow@mvista.com>
> CC:
>
> <libstdc++@gcc.gnu.org>, <gdb@sources.redhat.com>
>
>
>
>On Wed, 28 Nov 2001, Daniel Jacobowitz wrote:
>
>>> For the curious, I've gotten all but two of the virtual function tests to
>>> pass in virtfuncs.exp.  I'm not entirely sure what's wrong with one of the
>>> others, and the other goes up as far as the parser (pEe->D::fd() yields
>>> "attempt to take address of value not in memory").  There's also a bunch of
>>> namespace problems, of course.
>>>
>>> I'll not be posting the patches for another day or two.  The way I do it now
>>> is grossly inefficient; I look through RTTI at every lookup instead of once
>>> per type.  It also depends on presence of RTTI.  There's not much I can do
>>> about that - or rather, I could, but AFAICT it would require walking the
>>> inheritance graph in the proper order and I don't have the machinery to do
>>> that easily.  I'm not heartbroken that we need RTTI for debugging though.
>>
>
>Nor am I.
>However:
>     * To: gdb-patches at sources dot redhat dot com
>     * Subject: Re: Using typeinfo functions to determine RTTI
>     * From: Tom Tromey <tromey at cygnus dot com>
>     * Date: 03 May 2000 09:41:50 -0600
>     * Newsgroups: cygnus.patches.gdb
>     * Organization: Cygnus Solutions
>     * References:
><Pine.LNX.4.10.10005020923450.14281-100000@propylaea.anduin.com>
><npu2ggf8g3.fsf@zwingli.cygnus.com>
>     * Reply-To: tromey at cygnus dot com
> (This was me):
> >> Does anyone mind if i use the typeinfo name, rather than
> >> the virtual table name, to figure out th real type of an object? It
> >> only matters if someone does -fno-rtti, i believe. But I have no
> >> idea how many people actually use that flag to save time/space in
> >> debugging executables.
>
> Jim> Almost all of Cygnus's customers use GDB to debug embedded apps,
> Jim> and space is often an issue there.  But I don't actually know how
> Jim> many of them use -fno-rtti.
>
> All Java programs are compiled with -fno-rtti.  This includes the C++
> component.  So presumably if this change is made it will make it even
> harder for me to debug libgcj.
>
This would also be unfortunate for Mozilla, which compiles -fno-rtti. 
 Debugging Mozilla using gdb is already extremely memory intensive, and 
being required to use RTTI would make it even worse.  :-/

Dan

Re: C++ debugging progress

[Dan Mosedale]

Daniel Berlin wrote:

> Subject:
>
> Re: C++ debugging progress
> From:
>
> Daniel Berlin <dan@cgsoftware.com>
> Date:
>
> Wed, 28 Nov 2001 02:43:43 -0500 (EST)
>
> To:
>
> Daniel Jacobowitz <drow@mvista.com>
> CC:
>
> <libstdc++@gcc.gnu.org>, <gdb@sources.redhat.com>
>
>
>
>On Wed, 28 Nov 2001, Daniel Jacobowitz wrote:
>
>>> For the curious, I've gotten all but two of the virtual function tests to
>>> pass in virtfuncs.exp.  I'm not entirely sure what's wrong with one of the
>>> others, and the other goes up as far as the parser (pEe->D::fd() yields
>>> "attempt to take address of value not in memory").  There's also a bunch of
>>> namespace problems, of course.
>>>
>>> I'll not be posting the patches for another day or two.  The way I do it now
>>> is grossly inefficient; I look through RTTI at every lookup instead of once
>>> per type.  It also depends on presence of RTTI.  There's not much I can do
>>> about that - or rather, I could, but AFAICT it would require walking the
>>> inheritance graph in the proper order and I don't have the machinery to do
>>> that easily.  I'm not heartbroken that we need RTTI for debugging though.
>>
>
>Nor am I.
>However:
>     * To: gdb-patches at sources dot redhat dot com
>     * Subject: Re: Using typeinfo functions to determine RTTI
>     * From: Tom Tromey <tromey at cygnus dot com>
>     * Date: 03 May 2000 09:41:50 -0600
>     * Newsgroups: cygnus.patches.gdb
>     * Organization: Cygnus Solutions
>     * References:
><Pine.LNX.4.10.10005020923450.14281-100000@propylaea.anduin.com>
><npu2ggf8g3.fsf@zwingli.cygnus.com>
>     * Reply-To: tromey at cygnus dot com
> (This was me):
> >> Does anyone mind if i use the typeinfo name, rather than
> >> the virtual table name, to figure out th real type of an object? It
> >> only matters if someone does -fno-rtti, i believe. But I have no
> >> idea how many people actually use that flag to save time/space in
> >> debugging executables.
>
> Jim> Almost all of Cygnus's customers use GDB to debug embedded apps,
> Jim> and space is often an issue there.  But I don't actually know how
> Jim> many of them use -fno-rtti.
>
> All Java programs are compiled with -fno-rtti.  This includes the C++
> component.  So presumably if this change is made it will make it even
> harder for me to debug libgcj.
>
This would also be unfortunate for Mozilla, which compiles -fno-rtti. 
 Debugging Mozilla using gdb is already extremely memory intensive, and 
being required to use RTTI would make it even worse.  :-/

Dan

Re: C++ debugging progress

[Daniel Berlin]

On Wed, 28 Nov 2001, Daniel Jacobowitz wrote:

> For the curious, I've gotten all but two of the virtual function tests to
> pass in virtfuncs.exp.  I'm not entirely sure what's wrong with one of the
> others, and the other goes up as far as the parser (pEe->D::fd() yields
> "attempt to take address of value not in memory").  There's also a bunch of
> namespace problems, of course.
>
> I'll not be posting the patches for another day or two.  The way I do it now
> is grossly inefficient; I look through RTTI at every lookup instead of once
> per type.  It also depends on presence of RTTI.  There's not much I can do
> about that - or rather, I could, but AFAICT it would require walking the
> inheritance graph in the proper order and I don't have the machinery to do
> that easily.  I'm not heartbroken that we need RTTI for debugging though.

Nor am I.
However:
     * To: gdb-patches at sources dot redhat dot com
     * Subject: Re: Using typeinfo functions to determine RTTI
     * From: Tom Tromey <tromey at cygnus dot com>
     * Date: 03 May 2000 09:41:50 -0600
     * Newsgroups: cygnus.patches.gdb
     * Organization: Cygnus Solutions
     * References:
<Pine.LNX.4.10.10005020923450.14281-100000@propylaea.anduin.com>
<npu2ggf8g3.fsf@zwingli.cygnus.com>
     * Reply-To: tromey at cygnus dot com
 (This was me):
 >> Does anyone mind if i use the typeinfo name, rather than
 >> the virtual table name, to figure out th real type of an object? It
 >> only matters if someone does -fno-rtti, i believe. But I have no
 >> idea how many people actually use that flag to save time/space in
 >> debugging executables.

 Jim> Almost all of Cygnus's customers use GDB to debug embedded apps,
 Jim> and space is often an issue there.  But I don't actually know how
 Jim> many of them use -fno-rtti.

 All Java programs are compiled with -fno-rtti.  This includes the C++
 component.  So presumably if this change is made it will make it even
 harder for me to debug libgcj.

 Tom

Re: C++ debugging progress

[Jason Merrill]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

> I'll not be posting the patches for another day or two.  The way I do it now
> is grossly inefficient; I look through RTTI at every lookup instead of once
> per type.  It also depends on presence of RTTI.  There's not much I can do
> about that - or rather, I could, but AFAICT it would require walking the
> inheritance graph in the proper order and I don't have the machinery to do
> that easily.  I'm not heartbroken that we need RTTI for debugging though.

So you're using the inheritance information in the RTTI rather than the debug
info?  That seems unfortunate.  I'm not sure why you would need to worry
about ordering; the debug info should tell you exactly where things are.
If it doesn't, it should probably be fixed.

Jason

Re: C++ debugging progress

[Jason Merrill]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

> I'll not be posting the patches for another day or two.  The way I do it now
> is grossly inefficient; I look through RTTI at every lookup instead of once
> per type.  It also depends on presence of RTTI.  There's not much I can do
> about that - or rather, I could, but AFAICT it would require walking the
> inheritance graph in the proper order and I don't have the machinery to do
> that easily.  I'm not heartbroken that we need RTTI for debugging though.

So you're using the inheritance information in the RTTI rather than the debug
info?  That seems unfortunate.  I'm not sure why you would need to worry
about ordering; the debug info should tell you exactly where things are.
If it doesn't, it should probably be fixed.

Jason

Re: C++ debugging progress

[Daniel Jacobowitz]

On Wed, Nov 28, 2001 at 09:31:07AM +0000, Jason Merrill wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > I'll not be posting the patches for another day or two.  The way I do it now
> > is grossly inefficient; I look through RTTI at every lookup instead of once
> > per type.  It also depends on presence of RTTI.  There's not much I can do
> > about that - or rather, I could, but AFAICT it would require walking the
> > inheritance graph in the proper order and I don't have the machinery to do
> > that easily.  I'm not heartbroken that we need RTTI for debugging though.
> 
> So you're using the inheritance information in the RTTI rather than the debug
> info?  That seems unfortunate.  I'm not sure why you would need to worry
> about ordering; the debug info should tell you exactly where things are.
> If it doesn't, it should probably be fixed.

In that case, the debug info absolutely needs to be fixed.

(I'm looking at stabs here.  I haven't tried to see what Dwarf2 emits
yet.  I don't have my head wrapped around Dwarf2.  Yeah, I know, I
should be using it.)

Consider this:

struct Base { int xxx; };
struct Left : public virtual Base { int yyy; };
struct Right : public virtual Base { int zzz; };
struct Bottom : public Left, public Right { int bbb; };

int main() { struct Bottom bzz; return 1; }

The question, of course, is:  Where's bzz.xxx?

Dwarf2 first:
 <1><115>: Abbrev Number: 15 (DW_TAG_structure_type)
     DW_AT_sibling     : <1c2>  
     DW_AT_name        : Bottom 
     DW_AT_byte_size   : 24     
     DW_AT_decl_file   : 1      
     DW_AT_decl_line   : 4      
     DW_AT_containing_type: <22e>       
 <2><128>: Abbrev Number: 16 (DW_TAG_inheritance)
     DW_AT_type        : <22e>  
     DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst: 0; )
     DW_AT_accessibility: 1     (public)
 <2><131>: Abbrev Number: 16 (DW_TAG_inheritance)
     DW_AT_type        : <2df>  
     DW_AT_data_member_location: 2 byte block: 23 8 (DW_OP_plus_uconst: 8; )
     DW_AT_accessibility: 1     (public)
 <2><13a>: Abbrev Number: 3 (DW_TAG_member)
     DW_AT_name        : bbb    
     DW_AT_decl_file   : 1      
     DW_AT_decl_line   : 4      
     DW_AT_type        : <cd>   
     DW_AT_data_member_location: 2 byte block: 23 10 (DW_OP_plus_uconst: 16; )

Do you see it?  I don't, and I'm pretty sure it's not there.  It's at
+20.  That's not the best piece of information, though; what would be
more useful would be the vtable offset, in a Bottom vtable, for the
vbase offset.  That saves us a whole lot of grubbing around through
memory.  That's not there either, or in the entry for Left where it
would be logical to have it:

 <1><22e>: Abbrev Number: 15 (DW_TAG_structure_type)
     DW_AT_sibling     : <2df>  
     DW_AT_name        : Left   
     DW_AT_byte_size   : 12     
     DW_AT_decl_file   : 1      
     DW_AT_decl_line   : 2      
     DW_AT_containing_type: <22e>       
 <2><23f>: Abbrev Number: 22 (DW_TAG_inheritance)
     DW_AT_type        : <56>   
     DW_AT_data_member_location: 2 byte block: 23 8 (DW_OP_plus_uconst: 8; )
     DW_AT_virtuality  : 1      (virtual)
     DW_AT_accessibility: 1     (public)
 <2><249>: Abbrev Number: 23 (DW_TAG_member)
     DW_AT_name        : _vptr.Left     
     DW_AT_type        : <3b1>  
     DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst: 0; )
     DW_AT_artificial  : 1      
 <2><25d>: Abbrev Number: 3 (DW_TAG_member)
     DW_AT_name        : yyy    
     DW_AT_decl_file   : 1      
     DW_AT_decl_line   : 2      
     DW_AT_type        : <cd>   
     DW_AT_data_member_location: 2 byte block: 23 4 (DW_OP_plus_uconst: 4; )

No dice.


Meanwhile, in stabs gunk, member functions trimmed for brevity:
        .stabs "Bottom:Tt(0,32)=s24!2,020,(0,38)=xsLeft:;
		0264,(0,39)=xsRight:;bbb:(0,1),128,32;
		<snip>;;
		~%(0,38);"

That tells me that it's 24 bytes, that it has a Left at 0 bits and a
Right at 8 bits and int bbb at 128 bits, and that its vptr is in the
Left.

The Left says:
        .stabs "Left:Tt(0,317)=s12!1,1264,(0,25);.vf(0,317):(0,329),0;
		yyy:(0,1),32,32;
		<snip>;;
		~%(0,317);"

So it's 12 bytes, has a (virtual) Base at 64 bits, a vptr at 0 bits,
and int yyy at 32 bits.  That doesn't tell me anything at all.


So I've got the inheritence graph now, from either Dwarf2 or stabs. 
That is, technically, enough information for me to figure out the
layout of the vbase and vcall offsets.  But that's hideously
complicated!  If you see a better way, I'd love to know it.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: C++ debugging progress

[Daniel Jacobowitz]

On Wed, Nov 28, 2001 at 09:31:07AM +0000, Jason Merrill wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > I'll not be posting the patches for another day or two.  The way I do it now
> > is grossly inefficient; I look through RTTI at every lookup instead of once
> > per type.  It also depends on presence of RTTI.  There's not much I can do
> > about that - or rather, I could, but AFAICT it would require walking the
> > inheritance graph in the proper order and I don't have the machinery to do
> > that easily.  I'm not heartbroken that we need RTTI for debugging though.
> 
> So you're using the inheritance information in the RTTI rather than the debug
> info?  That seems unfortunate.  I'm not sure why you would need to worry
> about ordering; the debug info should tell you exactly where things are.
> If it doesn't, it should probably be fixed.

In that case, the debug info absolutely needs to be fixed.

(I'm looking at stabs here.  I haven't tried to see what Dwarf2 emits
yet.  I don't have my head wrapped around Dwarf2.  Yeah, I know, I
should be using it.)

Consider this:

struct Base { int xxx; };
struct Left : public virtual Base { int yyy; };
struct Right : public virtual Base { int zzz; };
struct Bottom : public Left, public Right { int bbb; };

int main() { struct Bottom bzz; return 1; }

The question, of course, is:  Where's bzz.xxx?

Dwarf2 first:
 <1><115>: Abbrev Number: 15 (DW_TAG_structure_type)
     DW_AT_sibling     : <1c2>  
     DW_AT_name        : Bottom 
     DW_AT_byte_size   : 24     
     DW_AT_decl_file   : 1      
     DW_AT_decl_line   : 4      
     DW_AT_containing_type: <22e>       
 <2><128>: Abbrev Number: 16 (DW_TAG_inheritance)
     DW_AT_type        : <22e>  
     DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst: 0; )
     DW_AT_accessibility: 1     (public)
 <2><131>: Abbrev Number: 16 (DW_TAG_inheritance)
     DW_AT_type        : <2df>  
     DW_AT_data_member_location: 2 byte block: 23 8 (DW_OP_plus_uconst: 8; )
     DW_AT_accessibility: 1     (public)
 <2><13a>: Abbrev Number: 3 (DW_TAG_member)
     DW_AT_name        : bbb    
     DW_AT_decl_file   : 1      
     DW_AT_decl_line   : 4      
     DW_AT_type        : <cd>   
     DW_AT_data_member_location: 2 byte block: 23 10 (DW_OP_plus_uconst: 16; )

Do you see it?  I don't, and I'm pretty sure it's not there.  It's at
+20.  That's not the best piece of information, though; what would be
more useful would be the vtable offset, in a Bottom vtable, for the
vbase offset.  That saves us a whole lot of grubbing around through
memory.  That's not there either, or in the entry for Left where it
would be logical to have it:

 <1><22e>: Abbrev Number: 15 (DW_TAG_structure_type)
     DW_AT_sibling     : <2df>  
     DW_AT_name        : Left   
     DW_AT_byte_size   : 12     
     DW_AT_decl_file   : 1      
     DW_AT_decl_line   : 2      
     DW_AT_containing_type: <22e>       
 <2><23f>: Abbrev Number: 22 (DW_TAG_inheritance)
     DW_AT_type        : <56>   
     DW_AT_data_member_location: 2 byte block: 23 8 (DW_OP_plus_uconst: 8; )
     DW_AT_virtuality  : 1      (virtual)
     DW_AT_accessibility: 1     (public)
 <2><249>: Abbrev Number: 23 (DW_TAG_member)
     DW_AT_name        : _vptr.Left     
     DW_AT_type        : <3b1>  
     DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst: 0; )
     DW_AT_artificial  : 1      
 <2><25d>: Abbrev Number: 3 (DW_TAG_member)
     DW_AT_name        : yyy    
     DW_AT_decl_file   : 1      
     DW_AT_decl_line   : 2      
     DW_AT_type        : <cd>   
     DW_AT_data_member_location: 2 byte block: 23 4 (DW_OP_plus_uconst: 4; )

No dice.


Meanwhile, in stabs gunk, member functions trimmed for brevity:
        .stabs "Bottom:Tt(0,32)=s24!2,020,(0,38)=xsLeft:;
		0264,(0,39)=xsRight:;bbb:(0,1),128,32;
		<snip>;;
		~%(0,38);"

That tells me that it's 24 bytes, that it has a Left at 0 bits and a
Right at 8 bits and int bbb at 128 bits, and that its vptr is in the
Left.

The Left says:
        .stabs "Left:Tt(0,317)=s12!1,1264,(0,25);.vf(0,317):(0,329),0;
		yyy:(0,1),32,32;
		<snip>;;
		~%(0,317);"

So it's 12 bytes, has a (virtual) Base at 64 bits, a vptr at 0 bits,
and int yyy at 32 bits.  That doesn't tell me anything at all.


So I've got the inheritence graph now, from either Dwarf2 or stabs. 
That is, technically, enough information for me to figure out the
layout of the vbase and vcall offsets.  But that's hideously
complicated!  If you see a better way, I'd love to know it.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: C++ debugging progress

[Daniel Berlin]

On Wed, 28 Nov 2001, Daniel Jacobowitz wrote:

> On Wed, Nov 28, 2001 at 09:31:07AM +0000, Jason Merrill wrote:
> > >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> >
> > > I'll not be posting the patches for another day or two.  The way I do it now
> > > is grossly inefficient; I look through RTTI at every lookup instead of once
> > > per type.  It also depends on presence of RTTI.  There's not much I can do
> > > about that - or rather, I could, but AFAICT it would require walking the
> > > inheritance graph in the proper order and I don't have the machinery to do
> > > that easily.  I'm not heartbroken that we need RTTI for debugging though.
> >
> > So you're using the inheritance information in the RTTI rather than the debug
> > info?  That seems unfortunate.  I'm not sure why you would need to worry
> > about ordering; the debug info should tell you exactly where things are.
> > If it doesn't, it should probably be fixed.
>
> In that case, the debug info absolutely needs to be fixed.
>
> (I'm looking at stabs here.  I haven't tried to see what Dwarf2 emits
> yet.  I don't have my head wrapped around Dwarf2.  Yeah, I know, I
> should be using it.)
>
> Consider this:
>
> struct Base { int xxx; };
> struct Left : public virtual Base { int yyy; };
> struct Right : public virtual Base { int zzz; };
> struct Bottom : public Left, public Right { int bbb; };
>
> int main() { struct Bottom bzz; return 1; }
>
> The question, of course, is:  Where's bzz.xxx?
>
> Dwarf2 first:
>  <1><115>: Abbrev Number: 15 (DW_TAG_structure_type)
>      DW_AT_sibling     : <1c2>
>      DW_AT_name        : Bottom
>      DW_AT_byte_size   : 24
>      DW_AT_decl_file   : 1
>      DW_AT_decl_line   : 4
>      DW_AT_containing_type: <22e>
>  <2><128>: Abbrev Number: 16 (DW_TAG_inheritance)
>      DW_AT_type        : <22e>
>      DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst: 0; )
>      DW_AT_accessibility: 1     (public)
>  <2><131>: Abbrev Number: 16 (DW_TAG_inheritance)
>      DW_AT_type        : <2df>
>      DW_AT_data_member_location: 2 byte block: 23 8 (DW_OP_plus_uconst: 8; )
>      DW_AT_accessibility: 1     (public)
>  <2><13a>: Abbrev Number: 3 (DW_TAG_member)
>      DW_AT_name        : bbb
>      DW_AT_decl_file   : 1
>      DW_AT_decl_line   : 4
>      DW_AT_type        : <cd>
>      DW_AT_data_member_location: 2 byte block: 23 10 (DW_OP_plus_uconst: 16; )
>
> Do you see it?  I don't, and I'm pretty sure it's not there.

Umm, look at type 2df and 22e.
I'm going to bet money xxx is there.

Re: C++ debugging progress

[Daniel Berlin]

On Wed, 28 Nov 2001, Daniel Jacobowitz wrote:

> On Wed, Nov 28, 2001 at 09:31:07AM +0000, Jason Merrill wrote:
> > >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> >
> > > I'll not be posting the patches for another day or two.  The way I do it now
> > > is grossly inefficient; I look through RTTI at every lookup instead of once
> > > per type.  It also depends on presence of RTTI.  There's not much I can do
> > > about that - or rather, I could, but AFAICT it would require walking the
> > > inheritance graph in the proper order and I don't have the machinery to do
> > > that easily.  I'm not heartbroken that we need RTTI for debugging though.
> >
> > So you're using the inheritance information in the RTTI rather than the debug
> > info?  That seems unfortunate.  I'm not sure why you would need to worry
> > about ordering; the debug info should tell you exactly where things are.
> > If it doesn't, it should probably be fixed.
>
> In that case, the debug info absolutely needs to be fixed.
>
> (I'm looking at stabs here.  I haven't tried to see what Dwarf2 emits
> yet.  I don't have my head wrapped around Dwarf2.  Yeah, I know, I
> should be using it.)
>
> Consider this:
>
> struct Base { int xxx; };
> struct Left : public virtual Base { int yyy; };
> struct Right : public virtual Base { int zzz; };
> struct Bottom : public Left, public Right { int bbb; };
>
> int main() { struct Bottom bzz; return 1; }
>
> The question, of course, is:  Where's bzz.xxx?
>
> Dwarf2 first:
>  <1><115>: Abbrev Number: 15 (DW_TAG_structure_type)
>      DW_AT_sibling     : <1c2>
>      DW_AT_name        : Bottom
>      DW_AT_byte_size   : 24
>      DW_AT_decl_file   : 1
>      DW_AT_decl_line   : 4
>      DW_AT_containing_type: <22e>
>  <2><128>: Abbrev Number: 16 (DW_TAG_inheritance)
>      DW_AT_type        : <22e>
>      DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst: 0; )
>      DW_AT_accessibility: 1     (public)
>  <2><131>: Abbrev Number: 16 (DW_TAG_inheritance)
>      DW_AT_type        : <2df>
>      DW_AT_data_member_location: 2 byte block: 23 8 (DW_OP_plus_uconst: 8; )
>      DW_AT_accessibility: 1     (public)
>  <2><13a>: Abbrev Number: 3 (DW_TAG_member)
>      DW_AT_name        : bbb
>      DW_AT_decl_file   : 1
>      DW_AT_decl_line   : 4
>      DW_AT_type        : <cd>
>      DW_AT_data_member_location: 2 byte block: 23 10 (DW_OP_plus_uconst: 16; )
>
> Do you see it?  I don't, and I'm pretty sure it's not there.

Umm, look at type 2df and 22e.
I'm going to bet money xxx is there.

Re: C++ debugging progress

[Daniel Jacobowitz]

On Wed, Nov 28, 2001 at 01:36:28PM -0500, Daniel Berlin wrote:
> > Dwarf2 first:
> >  <1><115>: Abbrev Number: 15 (DW_TAG_structure_type)
> >      DW_AT_sibling     : <1c2>
> >      DW_AT_name        : Bottom
> >      DW_AT_byte_size   : 24
> >      DW_AT_decl_file   : 1
> >      DW_AT_decl_line   : 4
> >      DW_AT_containing_type: <22e>
> >  <2><128>: Abbrev Number: 16 (DW_TAG_inheritance)
> >      DW_AT_type        : <22e>
> >      DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst: 0; )
> >      DW_AT_accessibility: 1     (public)
> >  <2><131>: Abbrev Number: 16 (DW_TAG_inheritance)
> >      DW_AT_type        : <2df>
> >      DW_AT_data_member_location: 2 byte block: 23 8 (DW_OP_plus_uconst: 8; )
> >      DW_AT_accessibility: 1     (public)
> >  <2><13a>: Abbrev Number: 3 (DW_TAG_member)
> >      DW_AT_name        : bbb
> >      DW_AT_decl_file   : 1
> >      DW_AT_decl_line   : 4
> >      DW_AT_type        : <cd>
> >      DW_AT_data_member_location: 2 byte block: 23 10 (DW_OP_plus_uconst: 16; )
> >
> > Do you see it?  I don't, and I'm pretty sure it's not there.
> 
> Umm, look at type 2df and 22e.
> I'm going to bet money xxx is there.

You owe me some money.

Both 22e and 2df are marked as inheriting from Base, which is <56> (I
included 22e in the original message).  They contain:

 <2><23f>: Abbrev Number: 22 (DW_TAG_inheritance)
     DW_AT_type        : <56>
     DW_AT_data_member_location: 2 byte block: 23 8 (DW_OP_plus_uconst: 8; )
     DW_AT_virtuality  : 1      (virtual)
     DW_AT_accessibility: 1     (public)

That tells me where xxx would be, inside the <56> at offset +8, if my
object was of type 2df or 22e.  It isn't, it's of type 115.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: C++ debugging progress

[Daniel Jacobowitz]

On Wed, Nov 28, 2001 at 01:36:28PM -0500, Daniel Berlin wrote:
> > Dwarf2 first:
> >  <1><115>: Abbrev Number: 15 (DW_TAG_structure_type)
> >      DW_AT_sibling     : <1c2>
> >      DW_AT_name        : Bottom
> >      DW_AT_byte_size   : 24
> >      DW_AT_decl_file   : 1
> >      DW_AT_decl_line   : 4
> >      DW_AT_containing_type: <22e>
> >  <2><128>: Abbrev Number: 16 (DW_TAG_inheritance)
> >      DW_AT_type        : <22e>
> >      DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst: 0; )
> >      DW_AT_accessibility: 1     (public)
> >  <2><131>: Abbrev Number: 16 (DW_TAG_inheritance)
> >      DW_AT_type        : <2df>
> >      DW_AT_data_member_location: 2 byte block: 23 8 (DW_OP_plus_uconst: 8; )
> >      DW_AT_accessibility: 1     (public)
> >  <2><13a>: Abbrev Number: 3 (DW_TAG_member)
> >      DW_AT_name        : bbb
> >      DW_AT_decl_file   : 1
> >      DW_AT_decl_line   : 4
> >      DW_AT_type        : <cd>
> >      DW_AT_data_member_location: 2 byte block: 23 10 (DW_OP_plus_uconst: 16; )
> >
> > Do you see it?  I don't, and I'm pretty sure it's not there.
> 
> Umm, look at type 2df and 22e.
> I'm going to bet money xxx is there.

You owe me some money.

Both 22e and 2df are marked as inheriting from Base, which is <56> (I
included 22e in the original message).  They contain:

 <2><23f>: Abbrev Number: 22 (DW_TAG_inheritance)
     DW_AT_type        : <56>
     DW_AT_data_member_location: 2 byte block: 23 8 (DW_OP_plus_uconst: 8; )
     DW_AT_virtuality  : 1      (virtual)
     DW_AT_accessibility: 1     (public)

That tells me where xxx would be, inside the <56> at offset +8, if my
object was of type 2df or 22e.  It isn't, it's of type 115.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: C++ debugging progress

[Jason Merrill]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

> On Wed, Nov 28, 2001 at 09:31:07AM +0000, Jason Merrill wrote:

>> So you're using the inheritance information in the RTTI rather than the debug
>> info?  That seems unfortunate.  I'm not sure why you would need to worry
>> about ordering; the debug info should tell you exactly where things are.
>> If it doesn't, it should probably be fixed.

> In that case, the debug info absolutely needs to be fixed.

>  <1><22e>: Abbrev Number: 15 (DW_TAG_structure_type)
>      DW_AT_sibling     : <2df>  
>      DW_AT_name        : Left   
>      DW_AT_byte_size   : 12     
>      DW_AT_decl_file   : 1      
>      DW_AT_decl_line   : 2      
>      DW_AT_containing_type: <22e>       
>  <2><23f>: Abbrev Number: 22 (DW_TAG_inheritance)
>      DW_AT_type        : <56>   
>      DW_AT_data_member_location: 2 byte block: 23 8 (DW_OP_plus_uconst: 8; )
>      DW_AT_virtuality  : 1      (virtual)
>      DW_AT_accessibility: 1     (public)

Yep.  Since Base is a virtual base of Left, the DW_AT_data_member_location
here should be a complex expression telling the debugger to go through the
vtable.  I'll get on it.

I'll also change the stabs output to give the offset within the vtable
rather than the offset of the base in a complete object; gdb will still
need to be clever enough to know what to do with it.

Jason

Re: C++ debugging progress

[Jason Merrill]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

> On Wed, Nov 28, 2001 at 09:31:07AM +0000, Jason Merrill wrote:

>> So you're using the inheritance information in the RTTI rather than the debug
>> info?  That seems unfortunate.  I'm not sure why you would need to worry
>> about ordering; the debug info should tell you exactly where things are.
>> If it doesn't, it should probably be fixed.

> In that case, the debug info absolutely needs to be fixed.

>  <1><22e>: Abbrev Number: 15 (DW_TAG_structure_type)
>      DW_AT_sibling     : <2df>  
>      DW_AT_name        : Left   
>      DW_AT_byte_size   : 12     
>      DW_AT_decl_file   : 1      
>      DW_AT_decl_line   : 2      
>      DW_AT_containing_type: <22e>       
>  <2><23f>: Abbrev Number: 22 (DW_TAG_inheritance)
>      DW_AT_type        : <56>   
>      DW_AT_data_member_location: 2 byte block: 23 8 (DW_OP_plus_uconst: 8; )
>      DW_AT_virtuality  : 1      (virtual)
>      DW_AT_accessibility: 1     (public)

Yep.  Since Base is a virtual base of Left, the DW_AT_data_member_location
here should be a complex expression telling the debugger to go through the
vtable.  I'll get on it.

I'll also change the stabs output to give the offset within the vtable
rather than the offset of the base in a complete object; gdb will still
need to be clever enough to know what to do with it.

Jason

Re: C++ debugging progress

[Daniel Jacobowitz]

On Wed, Nov 28, 2001 at 07:40:37PM +0000, Jason Merrill wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > On Wed, Nov 28, 2001 at 09:31:07AM +0000, Jason Merrill wrote:
> 
> >> So you're using the inheritance information in the RTTI rather than the debug
> >> info?  That seems unfortunate.  I'm not sure why you would need to worry
> >> about ordering; the debug info should tell you exactly where things are.
> >> If it doesn't, it should probably be fixed.
> 
> > In that case, the debug info absolutely needs to be fixed.
> 
> >  <1><22e>: Abbrev Number: 15 (DW_TAG_structure_type)
> >      DW_AT_sibling     : <2df>  
> >      DW_AT_name        : Left   
> >      DW_AT_byte_size   : 12     
> >      DW_AT_decl_file   : 1      
> >      DW_AT_decl_line   : 2      
> >      DW_AT_containing_type: <22e>       
> >  <2><23f>: Abbrev Number: 22 (DW_TAG_inheritance)
> >      DW_AT_type        : <56>   
> >      DW_AT_data_member_location: 2 byte block: 23 8 (DW_OP_plus_uconst: 8; )
> >      DW_AT_virtuality  : 1      (virtual)
> >      DW_AT_accessibility: 1     (public)
> 
> Yep.  Since Base is a virtual base of Left, the DW_AT_data_member_location
> here should be a complex expression telling the debugger to go through the
> vtable.  I'll get on it.
> 
> I'll also change the stabs output to give the offset within the vtable
> rather than the offset of the base in a complete object; gdb will still
> need to be clever enough to know what to do with it.

I should add: is there some way we can disambiguate correct and
incorrect debug info after this fix?  For Dwarf2 I see how to do it
pretty easily.  Would an explicit minus sign work?  I think GDB won't
croak on that.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: C++ debugging progress

[Daniel Jacobowitz]

On Wed, Nov 28, 2001 at 07:40:37PM +0000, Jason Merrill wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > On Wed, Nov 28, 2001 at 09:31:07AM +0000, Jason Merrill wrote:
> 
> >> So you're using the inheritance information in the RTTI rather than the debug
> >> info?  That seems unfortunate.  I'm not sure why you would need to worry
> >> about ordering; the debug info should tell you exactly where things are.
> >> If it doesn't, it should probably be fixed.
> 
> > In that case, the debug info absolutely needs to be fixed.
> 
> >  <1><22e>: Abbrev Number: 15 (DW_TAG_structure_type)
> >      DW_AT_sibling     : <2df>  
> >      DW_AT_name        : Left   
> >      DW_AT_byte_size   : 12     
> >      DW_AT_decl_file   : 1      
> >      DW_AT_decl_line   : 2      
> >      DW_AT_containing_type: <22e>       
> >  <2><23f>: Abbrev Number: 22 (DW_TAG_inheritance)
> >      DW_AT_type        : <56>   
> >      DW_AT_data_member_location: 2 byte block: 23 8 (DW_OP_plus_uconst: 8; )
> >      DW_AT_virtuality  : 1      (virtual)
> >      DW_AT_accessibility: 1     (public)
> 
> Yep.  Since Base is a virtual base of Left, the DW_AT_data_member_location
> here should be a complex expression telling the debugger to go through the
> vtable.  I'll get on it.
> 
> I'll also change the stabs output to give the offset within the vtable
> rather than the offset of the base in a complete object; gdb will still
> need to be clever enough to know what to do with it.

I should add: is there some way we can disambiguate correct and
incorrect debug info after this fix?  For Dwarf2 I see how to do it
pretty easily.  Would an explicit minus sign work?  I think GDB won't
croak on that.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: C++ debugging progress

[Jason Merrill]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

>>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:

> Yep.  Since Base is a virtual base of Left, the DW_AT_data_member_location
> here should be a complex expression telling the debugger to go through the
> vtable.  I'll get on it.

> I'll also change the stabs output to give the offset within the vtable
> rather than the offset of the base in a complete object; gdb will still
> need to be clever enough to know what to do with it.

Please give this a spin; gdb doesn't like it, but I think it's correct.
Note that the offset given in the stabs output should be treated as
negative, so for V3 objects,

  BaseAddr = LeftAddr + *((*LeftAddr) - Offset)

The dwarf2 output is the above encoded in reverse Polish notation.  I
suppose we could rely on gdb to know the equation for dwarf, too, but that
would be nonconforming and only saves four bytes.

2001-11-28  Jason Merrill  <jason@redhat.com>

	* dwarf2out.c (add_data_member_location_attribute): Do the
	right thing for virtual bases.
	* dbxout.c (dbxout_type): For a virtual base, print the offset
	within the vtable.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 4161 bytes --]

*** dwarf2out.c.~1~	Fri Nov 23 17:27:50 2001
--- dwarf2out.c	Wed Nov 28 20:42:37 2001
*************** add_data_member_location_attribute (die,
*** 8407,8434 ****
       dw_die_ref die;
       tree decl;
  {
!   unsigned long offset;
!   dw_loc_descr_ref loc_descr;
!   enum dwarf_location_atom op;
  
    if (TREE_CODE (decl) == TREE_VEC)
!     offset = tree_low_cst (BINFO_OFFSET (decl), 0);
    else
      offset = field_byte_offset (decl);
  
!   /* The DWARF2 standard says that we should assume that the structure address
!      is already on the stack, so we can specify a structure field address
!      by using DW_OP_plus_uconst.  */
  
  #ifdef MIPS_DEBUGGING_INFO
!   /* ??? The SGI dwarf reader does not handle the DW_OP_plus_uconst operator
!      correctly.  It works only if we leave the offset on the stack.  */
!   op = DW_OP_constu;
  #else
!   op = DW_OP_plus_uconst;
  #endif
  
!   loc_descr = new_loc_descr (op, offset, 0);
    add_AT_loc (die, DW_AT_data_member_location, loc_descr);
  }
  
--- 8407,8471 ----
       dw_die_ref die;
       tree decl;
  {
!   long offset;
!   dw_loc_descr_ref loc_descr = 0;
  
    if (TREE_CODE (decl) == TREE_VEC)
!     {
!       /* We're working on the TAG_inheritance for a base class.  */
! 
!       if (TREE_VIA_VIRTUAL (decl))
! 	{
! 	  /* For C++ virtual bases we can't just use BINFO_OFFSET, as they
! 	     aren't at a fixed offset from all (sub)objects of the same type.
! 	     We need to extract the appropriate offset from our vtable.  */
! 
! 	  dw_loc_descr_ref tmp;
! 	  /* Make a copy of the object address.  */
! 	  tmp = new_loc_descr (DW_OP_dup, 0, 0);
! 	  add_loc_descr (&loc_descr, tmp);
! 	  /* Extract the vtable address.  */
! 	  tmp = new_loc_descr (DW_OP_deref, 0, 0);
! 	  add_loc_descr (&loc_descr, tmp);
! 	  /* Calculate the address of the offset.  */
! 	  offset = tree_low_cst (BINFO_VPTR_FIELD (decl), 0);
! 	  if (offset >= 0)
! 	    abort ();
! 	  tmp = int_loc_descriptor (-offset);
! 	  add_loc_descr (&loc_descr, tmp);
! 	  tmp = new_loc_descr (DW_OP_minus, 0, 0);
! 	  add_loc_descr (&loc_descr, tmp);
! 	  /* Extract the offset.  */
! 	  tmp = new_loc_descr (DW_OP_deref, 0, 0);
! 	  add_loc_descr (&loc_descr, tmp);
! 	  /* Add it to the object address.  */
! 	  tmp = new_loc_descr (DW_OP_plus, 0, 0);
! 	  add_loc_descr (&loc_descr, tmp);
! 	}
!       else
! 	offset = tree_low_cst (BINFO_OFFSET (decl), 0);
!     }
    else
      offset = field_byte_offset (decl);
  
!   if (! loc_descr)
!     {
!       enum dwarf_location_atom op;
! 
!       /* The DWARF2 standard says that we should assume that the structure address
! 	 is already on the stack, so we can specify a structure field address
! 	 by using DW_OP_plus_uconst.  */
  
  #ifdef MIPS_DEBUGGING_INFO
!       /* ??? The SGI dwarf reader does not handle the DW_OP_plus_uconst operator
! 	 correctly.  It works only if we leave the offset on the stack.  */
!       op = DW_OP_constu;
  #else
!       op = DW_OP_plus_uconst;
  #endif
  
!       loc_descr = new_loc_descr (op, offset, 0);
!     }
    add_AT_loc (die, DW_AT_data_member_location, loc_descr);
  }
  
*** dbxout.c.~1~	Thu Nov 15 16:59:31 2001
--- dbxout.c	Wed Nov 28 20:49:04 2001
*************** dbxout_type (type, full)
*** 1492,1499 ****
  		putc (TREE_VIA_VIRTUAL (child) ? '1' : '0', asmfile);
  		putc (TREE_VIA_PUBLIC (child) ? '2' : '0', asmfile);
  		CHARS (2);
! 		print_wide_int (tree_low_cst (BINFO_OFFSET (child), 0)
! 				* BITS_PER_UNIT);
  		putc (',', asmfile);
  		CHARS (1);
  		dbxout_type (BINFO_TYPE (child), 0);
--- 1492,1506 ----
  		putc (TREE_VIA_VIRTUAL (child) ? '1' : '0', asmfile);
  		putc (TREE_VIA_PUBLIC (child) ? '2' : '0', asmfile);
  		CHARS (2);
! 		if (TREE_VIA_VIRTUAL (child))
! 		  /* For a virtual base, print the (negative) offset within
! 		     the vtable where we must look to find the necessary
! 		     adjustment.  */
! 		  print_wide_int (-tree_low_cst (BINFO_VPTR_FIELD (child), 0)
! 				  * BITS_PER_UNIT);
! 		else
! 		  print_wide_int (tree_low_cst (BINFO_OFFSET (child), 0)
! 				  * BITS_PER_UNIT);
  		putc (',', asmfile);
  		CHARS (1);
  		dbxout_type (BINFO_TYPE (child), 0);

Re: C++ debugging progress

[Daniel Jacobowitz]

On Wed, Nov 28, 2001 at 09:03:04PM +0000, Jason Merrill wrote:
> >>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:
> 
> > Yep.  Since Base is a virtual base of Left, the DW_AT_data_member_location
> > here should be a complex expression telling the debugger to go through the
> > vtable.  I'll get on it.
> 
> > I'll also change the stabs output to give the offset within the vtable
> > rather than the offset of the base in a complete object; gdb will still
> > need to be clever enough to know what to do with it.
> 
> Please give this a spin; gdb doesn't like it, but I think it's correct.
> Note that the offset given in the stabs output should be treated as
> negative, so for V3 objects,
> 
>   BaseAddr = LeftAddr + *((*LeftAddr) - Offset)
> 
> The dwarf2 output is the above encoded in reverse Polish notation.  I
> suppose we could rely on gdb to know the equation for dwarf, too, but that
> would be nonconforming and only saves four bytes.
> 
> 2001-11-28  Jason Merrill  <jason@redhat.com>
> 
> 	* dwarf2out.c (add_data_member_location_attribute): Do the
> 	right thing for virtual bases.
> 	* dbxout.c (dbxout_type): For a virtual base, print the offset
> 	within the vtable.

I haven't looked at the Dwarf parts - I need to get my current stabs
project sorted out first - but with the removed minus sign, this
simplifies my stabs code tremendously and works just fine.  Any chance
of getting this into 3.0.3 also, or should I just maintain a local
patch?

As for the Dwarf bits, what I'll probably do for now is recognize this
specific form of expression and just stash the negative offset, so that
only the debug readers need to know how I got it.  That will be a bit
of a hack, but I've done worse, and conforming has some uses :)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: C++ debugging progress

[Jason Merrill]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

> Any chance of getting this into 3.0.3 also

The change seems to make things worse with gdb 5.1, so I'm not sure that
would be a good idea.

Jason

Re: C++ debugging progress

[Jason Merrill]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

> Any chance of getting this into 3.0.3 also

The change seems to make things worse with gdb 5.1, so I'm not sure that
would be a good idea.

Jason

Re: C++ debugging progress

[Daniel Jacobowitz]

On Thu, Nov 29, 2001 at 05:42:06PM +0000, Jason Merrill wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > Any chance of getting this into 3.0.3 also
> 
> The change seems to make things worse with gdb 5.1, so I'm not sure that
> would be a good idea.

To be honest, I'd rather the patch go in anyway.  C++ debugging for v3
is so broken in gdb 5.1 that it does not make a lot of sense to cater
to it.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: C++ debugging progress

[Daniel Jacobowitz]

On Thu, Nov 29, 2001 at 05:42:06PM +0000, Jason Merrill wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > Any chance of getting this into 3.0.3 also
> 
> The change seems to make things worse with gdb 5.1, so I'm not sure that
> would be a good idea.

To be honest, I'd rather the patch go in anyway.  C++ debugging for v3
is so broken in gdb 5.1 that it does not make a lot of sense to cater
to it.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: C++ debugging progress

[Kevin Buettner]

On Nov 29,  3:27pm, Daniel Jacobowitz wrote:

> On Thu, Nov 29, 2001 at 05:42:06PM +0000, Jason Merrill wrote:
> > >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> > 
> > > Any chance of getting this into 3.0.3 also
> > 
> > The change seems to make things worse with gdb 5.1, so I'm not sure that
> > would be a good idea.
> 
> To be honest, I'd rather the patch go in anyway.  C++ debugging for v3
> is so broken in gdb 5.1 that it does not make a lot of sense to cater
> to it.

FWIW, I agree with Daniel.  There's been talk of a possible gdb 5.1.1. 
I'd be all in favor of Daniel's C++ fixes going into 5.1.1 if Jason's
fixes go into a mainline gcc version.

Kevin

Re: C++ debugging progress

[Jason Merrill]

>>>>> "Kevin" == Kevin Buettner <kevinb@redhat.com> writes:

> FWIW, I agree with Daniel.  There's been talk of a possible gdb 5.1.1. 
> I'd be all in favor of Daniel's C++ fixes going into 5.1.1 if Jason's
> fixes go into a mainline gcc version.

Done.

Jason

Re: C++ debugging progress

[Jason Merrill]

>>>>> "Kevin" == Kevin Buettner <kevinb@redhat.com> writes:

> FWIW, I agree with Daniel.  There's been talk of a possible gdb 5.1.1. 
> I'd be all in favor of Daniel's C++ fixes going into 5.1.1 if Jason's
> fixes go into a mainline gcc version.

Done.

Jason

Re: C++ debugging progress

[Kevin Buettner]

On Nov 29,  3:27pm, Daniel Jacobowitz wrote:

> On Thu, Nov 29, 2001 at 05:42:06PM +0000, Jason Merrill wrote:
> > >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> > 
> > > Any chance of getting this into 3.0.3 also
> > 
> > The change seems to make things worse with gdb 5.1, so I'm not sure that
> > would be a good idea.
> 
> To be honest, I'd rather the patch go in anyway.  C++ debugging for v3
> is so broken in gdb 5.1 that it does not make a lot of sense to cater
> to it.

FWIW, I agree with Daniel.  There's been talk of a possible gdb 5.1.1. 
I'd be all in favor of Daniel's C++ fixes going into 5.1.1 if Jason's
fixes go into a mainline gcc version.

Kevin

Re: C++ debugging progress

[Benjamin Kosnik]

I'd like to give this work a spin when it gets in. Jason, I see that 
you've not posted to gcc-patches with this: can you let me know when it's 
in mainline gcc? I figure it's pretty pointless to try this without 
the gdb bits. Daniel, same with you, except gdb-patches.

thanks again to both of you,
benjamin

> To be honest, I'd rather the patch go in anyway.  C++ debugging for v3
> is so broken in gdb 5.1 that it does not make a lot of sense to cater
> to it.

Re: C++ debugging progress

[Benjamin Kosnik]

I'd like to give this work a spin when it gets in. Jason, I see that 
you've not posted to gcc-patches with this: can you let me know when it's 
in mainline gcc? I figure it's pretty pointless to try this without 
the gdb bits. Daniel, same with you, except gdb-patches.

thanks again to both of you,
benjamin

> To be honest, I'd rather the patch go in anyway.  C++ debugging for v3
> is so broken in gdb 5.1 that it does not make a lot of sense to cater
> to it.

Re: C++ debugging progress

[Daniel Jacobowitz]

On Wed, Nov 28, 2001 at 09:03:04PM +0000, Jason Merrill wrote:
> >>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:
> 
> > Yep.  Since Base is a virtual base of Left, the DW_AT_data_member_location
> > here should be a complex expression telling the debugger to go through the
> > vtable.  I'll get on it.
> 
> > I'll also change the stabs output to give the offset within the vtable
> > rather than the offset of the base in a complete object; gdb will still
> > need to be clever enough to know what to do with it.
> 
> Please give this a spin; gdb doesn't like it, but I think it's correct.
> Note that the offset given in the stabs output should be treated as
> negative, so for V3 objects,
> 
>   BaseAddr = LeftAddr + *((*LeftAddr) - Offset)
> 
> The dwarf2 output is the above encoded in reverse Polish notation.  I
> suppose we could rely on gdb to know the equation for dwarf, too, but that
> would be nonconforming and only saves four bytes.
> 
> 2001-11-28  Jason Merrill  <jason@redhat.com>
> 
> 	* dwarf2out.c (add_data_member_location_attribute): Do the
> 	right thing for virtual bases.
> 	* dbxout.c (dbxout_type): For a virtual base, print the offset
> 	within the vtable.

I haven't looked at the Dwarf parts - I need to get my current stabs
project sorted out first - but with the removed minus sign, this
simplifies my stabs code tremendously and works just fine.  Any chance
of getting this into 3.0.3 also, or should I just maintain a local
patch?

As for the Dwarf bits, what I'll probably do for now is recognize this
specific form of expression and just stash the negative offset, so that
only the debug readers need to know how I got it.  That will be a bit
of a hack, but I've done worse, and conforming has some uses :)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: C++ debugging progress

[Jason Merrill]

>>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:

> Yep.  Since Base is a virtual base of Left, the DW_AT_data_member_location
> here should be a complex expression telling the debugger to go through the
> vtable.  I'll get on it.

> I'll also change the stabs output to give the offset within the vtable
> rather than the offset of the base in a complete object; gdb will still
> need to be clever enough to know what to do with it.

Please give this a spin; gdb doesn't like it, but I think it's correct.
Note that the offset given in the stabs output should be treated as
negative, so for V3 objects,

  BaseAddr = LeftAddr + *((*LeftAddr) - Offset)

The dwarf2 output is the above encoded in reverse Polish notation.  I
suppose we could rely on gdb to know the equation for dwarf, too, but that
would be nonconforming and only saves four bytes.

2001-11-28  Jason Merrill  <jason@redhat.com>

	* dwarf2out.c (add_data_member_location_attribute): Do the
	right thing for virtual bases.
	* dbxout.c (dbxout_type): For a virtual base, print the offset
	within the vtable.

Re: C++ debugging progress

[Jason Merrill]

>>>>> "Daniel" == Daniel Jacobowitz <dmj+@andrew.cmu.edu> writes:

> OK, if I'm reading this at all correctly, the offset in the baseclass
> definition is assumed to be 0 for a virtual baseclass, and ignored; it
> is assumed that there will be a $vb later.  So that offset slot is a
> perfect place to put the information I need.  Just let me know if it is
> relative to the start of the vtable or to the vtable pointer.  That'll
> be enough information to do a much better job.

The vtable pointer.

> I should add: is there some way we can disambiguate correct and
> incorrect debug info after this fix?  For Dwarf2 I see how to do it
> pretty easily.  Would an explicit minus sign work?  I think GDB won't
> croak on that.

That would be fine; just remove the negation from the dbxout.c patch.

Jason

Re: C++ debugging progress

[Jason Merrill]

>>>>> "Daniel" == Daniel Jacobowitz <dmj+@andrew.cmu.edu> writes:

> OK, if I'm reading this at all correctly, the offset in the baseclass
> definition is assumed to be 0 for a virtual baseclass, and ignored; it
> is assumed that there will be a $vb later.  So that offset slot is a
> perfect place to put the information I need.  Just let me know if it is
> relative to the start of the vtable or to the vtable pointer.  That'll
> be enough information to do a much better job.

The vtable pointer.

> I should add: is there some way we can disambiguate correct and
> incorrect debug info after this fix?  For Dwarf2 I see how to do it
> pretty easily.  Would an explicit minus sign work?  I think GDB won't
> croak on that.

That would be fine; just remove the negation from the dbxout.c patch.

Jason