Re: C++ debugging progress

[Daniel Jacobowitz <drow at mvista dot com>]

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