From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: Jason Merrill Cc: libstdc++@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: C++ debugging progress Date: Wed, 28 Nov 2001 09:41:00 -0000 Message-id: <20011128124118.A23447@nevyn.them.org> References: <20011128020256.A9688@nevyn.them.org> X-SW-Source: 2001-11/msg00314.html On Wed, Nov 28, 2001 at 09:31:07AM +0000, Jason Merrill wrote: > >>>>> "Daniel" == Daniel Jacobowitz 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 : 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 : 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; ;; ~%(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; ;; ~%(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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21916 invoked by alias); 28 Nov 2001 17:41:01 -0000 Mailing-List: contact gdb-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21776 invoked from network); 28 Nov 2001 17:40:57 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by hostedprojects.ges.redhat.com with SMTP; 28 Nov 2001 17:40:57 -0000 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 1698hy-0006gV-00; Wed, 28 Nov 2001 12:41:18 -0500 Date: Wed, 21 Nov 2001 04:12:00 -0000 From: Daniel Jacobowitz To: Jason Merrill Cc: libstdc++@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: C++ debugging progress Message-ID: <20011128124118.A23447@nevyn.them.org> Mail-Followup-To: Jason Merrill , libstdc++@gcc.gnu.org, gdb@sources.redhat.com References: <20011128020256.A9688@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-SW-Source: 2001-11/txt/msg00207.txt.bz2 Message-ID: <20011121041200.eX6RWfzAibxDWkVUuB6wU9WEea8psEB2uk1snvO_RUA@z> On Wed, Nov 28, 2001 at 09:31:07AM +0000, Jason Merrill wrote: > >>>>> "Daniel" == Daniel Jacobowitz 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 : 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 : 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; ;; ~%(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; ;; ~%(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