From: Jason Merrill <jason@redhat.com>
To: libstdc++@gcc.gnu.org
Cc: gdb@sources.redhat.com
Subject: Re: C++ debugging progress
Date: Wed, 21 Nov 2001 16:38:00 -0000 [thread overview]
Message-ID: <wvlbshmy5fb.fsf@prospero.cambridge.redhat.com> (raw)
In-Reply-To: <wvly9kqy98q.fsf@prospero.cambridge.redhat.com> (Jason Merrill's message of "Wed, 28 Nov 2001 19:40:37 +0000")
[-- 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);
WARNING: multiple messages have this Message-ID
From: Jason Merrill <jason@redhat.com>
To: libstdc++@gcc.gnu.org
Cc: gdb@sources.redhat.com
Subject: Re: C++ debugging progress
Date: Wed, 28 Nov 2001 13:03:00 -0000 [thread overview]
Message-ID: <wvlbshmy5fb.fsf@prospero.cambridge.redhat.com> (raw)
Message-ID: <20011128130300.O5RrG6qJCv-Jx4NJ2bvDZTlOyOiUlz_T3ZJ_2_WmW3c@z> (raw)
In-Reply-To: <wvly9kqy98q.fsf@prospero.cambridge.redhat.com>
>>>>> "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.
next prev parent reply other threads:[~2001-11-28 21:03 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-27 23:03 Daniel Jacobowitz
2001-11-18 21:43 ` Daniel Jacobowitz
2001-11-19 9:04 ` Benjamin Kosnik
2001-11-27 23:36 ` Benjamin Kosnik
2001-11-19 11:16 ` Daniel Berlin
2001-11-21 13:37 ` Dan Mosedale
2001-11-28 12:25 ` Dan Mosedale
2001-11-27 23:43 ` Daniel Berlin
2001-11-19 13:41 ` Jason Merrill
2001-11-28 1:31 ` Jason Merrill
2001-11-28 9:41 ` Daniel Jacobowitz
2001-11-21 4:12 ` Daniel Jacobowitz
2001-11-21 5:06 ` Daniel Berlin
2001-11-28 10:36 ` Daniel Berlin
2001-11-28 10:49 ` Daniel Jacobowitz
2001-11-21 12:33 ` Daniel Jacobowitz
2001-11-28 11:41 ` Jason Merrill
2001-11-21 13:21 ` Jason Merrill
2001-11-21 13:42 ` Daniel Jacobowitz
2001-11-28 12:32 ` Daniel Jacobowitz
2001-11-21 16:38 ` Jason Merrill [this message]
2001-11-22 0:13 ` Daniel Jacobowitz
2001-11-24 22:52 ` Jason Merrill
2001-11-29 9:44 ` Jason Merrill
2001-11-29 12:28 ` Daniel Jacobowitz
2001-11-25 8:34 ` Daniel Jacobowitz
2001-11-25 9:01 ` Kevin Buettner
2001-11-25 10:30 ` Jason Merrill
2001-11-29 19:12 ` Jason Merrill
2001-11-29 13:11 ` Kevin Buettner
2001-11-29 12:50 ` Benjamin Kosnik
2001-11-25 8:40 ` Benjamin Kosnik
2001-11-28 13:31 ` Daniel Jacobowitz
2001-11-28 13:03 ` Jason Merrill
[not found] ` <20011128151819.A31514@nevyn.them.org>
2001-11-21 22:26 ` Jason Merrill
2001-11-28 13:14 ` Jason Merrill
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=wvlbshmy5fb.fsf@prospero.cambridge.redhat.com \
--to=jason@redhat.com \
--cc=gdb@sources.redhat.com \
--cc=libstdc++@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox