From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16803 invoked by alias); 28 Nov 2001 21:03:54 -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 16643 invoked from network); 28 Nov 2001 21:03:40 -0000 Received: from unknown (HELO localhost.localdomain) (62.30.164.150) by hostedprojects.ges.redhat.com with SMTP; 28 Nov 2001 21:03:40 -0000 Received: (from jason@localhost) by localhost.localdomain (8.11.6/8.11.6) id fASL35103302; Wed, 28 Nov 2001 21:03:05 GMT X-Authentication-Warning: localhost.localdomain: jason set sender to jason@redhat.com using -f To: libstdc++@gcc.gnu.org Cc: gdb@sources.redhat.com Subject: Re: C++ debugging progress References: <20011128020256.A9688@nevyn.them.org> <20011128124118.A23447@nevyn.them.org> From: Jason Merrill In-Reply-To: (Jason Merrill's message of "Wed, 28 Nov 2001 19:40:37 +0000") Date: Wed, 21 Nov 2001 16:38:00 -0000 Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SW-Source: 2001-11/txt/msg00217.txt.bz2 --=-=-= Content-length: 1083 >>>>> "Jason" == Jason Merrill 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 * 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. --=-=-= Content-Type: text/x-patch Content-Disposition: inline Content-length: 4161 *** 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); --=-=-=-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Merrill To: libstdc++@gcc.gnu.org Cc: gdb@sources.redhat.com Subject: Re: C++ debugging progress Date: Wed, 28 Nov 2001 13:03:00 -0000 Message-ID: References: <20011128020256.A9688@nevyn.them.org> <20011128124118.A23447@nevyn.them.org> X-SW-Source: 2001-11/msg00324.html Message-ID: <20011128130300.O5RrG6qJCv-Jx4NJ2bvDZTlOyOiUlz_T3ZJ_2_WmW3c@z> >>>>> "Jason" == Jason Merrill 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 * 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.