Re: c++ debugging hosed

Re: c++ debugging hosed

[Jason Merrill]

>>>>> "Benjamin" == Benjamin Kosnik <bkoz@redhat.com> writes:

> On x86/linux, both --with-dwarf2 and default gcc-3.x toolchains can no
> longer find RTTI info:

> --with-dwarf2:
> (gdb) p *this
> can't find class named `std::basic_filebuf<char, std::char_traits<char> >', as given by C++ RTTI

> default:
> (gdb) p *this
> Attempt to take contents of a non-pointer value.

> Sadly, this bug has been around for 2 weeks now. It's making debugging
> C++ code more difficult than it should be. Any hope for a quick fix?

I just updated my gdb for the first time in months and ran into the same
problem.  Looks like the V3 ABI support code isn't ready for prime time.
Until it is, you can disable it with this patch:

*** gnu-v3-abi.c.~1~	Wed Nov 14 12:33:51 2001
--- gnu-v3-abi.c	Wed Nov 14 15:59:39 2001
*************** init_gnuv3_ops (void)
*** 349,355 ****
--- 360,368 ----
  void
  _initialize_gnu_v3_abi (void)
  {
+ #if 0
    init_gnuv3_ops ();
  
    register_cp_abi (gnu_v3_abi_ops);
+ #endif
  }

Re: c++ debugging hosed

[Benjamin Kosnik]

Hey. Thanks for the hack.

> I just updated my gdb for the first time in months and ran into the same
> problem.  Looks like the V3 ABI support code isn't ready for prime time.
> Until it is, you can disable it with this patch:

Yay. I disabled it.

#include <sstream>

void test01()
{
  std::ostringstream oss; // break here
}

I'm still having some difficulty, however. In the above, 

(gdb) p oss
$1 = {<basic_ostream<char,std::char_traits<char> >> = 
{<basic_ios<char,std::char_traits<char> >> = <invalid address>, 
    _vptr.basic_ostream<char,std::char_traits<char> > = 0x80faa4c}, 
  _M_stringbuf = {<basic_streambuf<char,std::char_traits<char> >> = {
      _vptr.basic_streambuf<char,std::char_traits<char> > = 0x80faa88, 
      _M_buf = 0x811955c "", _M_buf_size = 0, _M_buf_size_opt = 512, 
      _M_buf_unified = false, _M_in_beg = 0x0, _M_in_cur = 0x0, 
      _M_in_end = 0x0, _M_out_beg = 0x811955c "", _M_out_cur = 0x811955c 
"", 
      _M_out_end = 0x811955c "", _M_mode = 16, _M_buf_locale = {static 
none = Internal: global symbol `_ZNSt6locale4noneE' found in 
/mnt/hd/src/src.gcc/libstdc++-v3/src/locale.cc psymtab but not in symtab.
_ZNSt6locale4noneE may be an inlined function, or may be a template function
(if a template, try specifying an instantiation: _ZNSt6locale4noneE<type>).
(gdb) p oss._M_streambuf
virtual baseclass botch

I haven't tried this with a dwarf2 toolchain yet, I will in a bit. 
Is there a last known good date for gdb so that I can revert my sources 
until this is fixed?

thanks,
benjamin

Re: c++ debugging hosed

[Benjamin Kosnik]

This also happens with dwarf2 enabled.

> I haven't tried this with a dwarf2 toolchain yet, I will in a bit. 

Re: c++ debugging hosed

[Eli Zaretskii]

> From: Jason Merrill <jason@redhat.com>
> Date: Wed, 14 Nov 2001 16:02:11 +0000
> 
> > --with-dwarf2:
> > (gdb) p *this
> > can't find class named `std::basic_filebuf<char, std::char_traits<char> >', as given by C++ RTTI
> 
> > default:
> > (gdb) p *this
> > Attempt to take contents of a non-pointer value.
> 
> > Sadly, this bug has been around for 2 weeks now. It's making debugging
> > C++ code more difficult than it should be. Any hope for a quick fix?
> 
> I just updated my gdb for the first time in months and ran into the same
> problem.  Looks like the V3 ABI support code isn't ready for prime time.
> Until it is, you can disable it with this patch:
> 
> *** gnu-v3-abi.c.~1~	Wed Nov 14 12:33:51 2001
> --- gnu-v3-abi.c	Wed Nov 14 15:59:39 2001
> *************** init_gnuv3_ops (void)
> *** 349,355 ****
> --- 360,368 ----
>   void
>   _initialize_gnu_v3_abi (void)
>   {
> + #if 0
>     init_gnuv3_ops ();
>   
>     register_cp_abi (gnu_v3_abi_ops);
> + #endif
>   }

The above code is in GDB 5.1, and it isn't disabled.  I'm about to
prepare a binary release of the DJGPP port, so I'd like to ask whether
people here would recommend commenting defining away this code.  Is
this only a DWARF2 issue, or is the same problem relevant to stabs,
say?

Re: c++ debugging hosed

[Daniel Berlin]

On Sun, 25 Nov 2001, Eli Zaretskii wrote:

> > From: Jason Merrill <jason@redhat.com>
> > Date: Wed, 14 Nov 2001 16:02:11 +0000
> >
> > > --with-dwarf2:
> > > (gdb) p *this
> > > can't find class named `std::basic_filebuf<char, std::char_traits<char> >', as given by C++ RTTI
> >
> > > default:
> > > (gdb) p *this
> > > Attempt to take contents of a non-pointer value.
> >
> > > Sadly, this bug has been around for 2 weeks now. It's making debugging
> > > C++ code more difficult than it should be. Any hope for a quick fix?
> >
> > I just updated my gdb for the first time in months and ran into the same
> > problem.  Looks like the V3 ABI support code isn't ready for prime time.
> > Until it is, you can disable it with this patch:
> >
> > *** gnu-v3-abi.c.~1~	Wed Nov 14 12:33:51 2001
> > --- gnu-v3-abi.c	Wed Nov 14 15:59:39 2001
> > *************** init_gnuv3_ops (void)
> > *** 349,355 ****
> > --- 360,368 ----
> >   void
> >   _initialize_gnu_v3_abi (void)
> >   {
> > + #if 0
> >     init_gnuv3_ops ();
> >
> >     register_cp_abi (gnu_v3_abi_ops);
> > + #endif
> >   }
>
> The above code is in GDB 5.1, and it isn't disabled.  I'm about to
> prepare a binary release of the DJGPP port, so I'd like to ask whether
> people here would recommend commenting defining away this code.  Is
> this only a DWARF2 issue, or is the same problem relevant to stabs,
> say?
>
No, it's relevant to STABS, too.
It's due to not properly searching virtual baseclasses.
I might still have the changes to do that somewhere, if someone wants
them.
--Dan

Re: c++ debugging hosed

[Benjamin Kosnik]

> No, it's relevant to STABS, too.
> It's due to not properly searching virtual baseclasses.
> I might still have the changes to do that somewhere, if someone wants
> them.

This has been broken for some time now. I'd appreciate it if it got 
fixed, so that C++ could be debugged properly.

-benjamin

Re: c++ debugging hosed

[Daniel Berlin]

On Sun, 25 Nov 2001, Benjamin Kosnik wrote:

>
> > No, it's relevant to STABS, too.
> > It's due to not properly searching virtual baseclasses.
> > I might still have the changes to do that somewhere, if someone wants
> > them.
>
> This has been broken for some time now. I'd appreciate it if it got
> fixed, so that C++ could be debugged properly.
I'm sure a lot of people would.
Unfortunately, it appears I don't have the code i had worked up to
abstract out the base class offset finding anymore.
What's happening is that GDB wants to know the baseclass offset, and
the routine it uses is tuned to either gnu-v2 or hp aCC (it checks
for something only hp's debug readers fill in, and if it doesn't find
it, it assumes gnu-v2), and the gnu-v2 code either returns the wrong
value (weird errors occur), or -1, which gives you "virtual baseclass
botch"/attempts to deref int values as pointers.

baseclass_offset needs to be abstracted into the cp abi model, and all
existing uses need to use it.

HTH somebody,
Dan

Re: c++ debugging hosed

[Benjamin Kosnik]

Thanks for the analysis Daniel.

> I'm sure a lot of people would.

Yep.

Re: c++ debugging hosed

[Daniel Jacobowitz]

On Sun, Nov 25, 2001 at 03:29:08PM -0500, Daniel Berlin wrote:
> 
> 
> On Sun, 25 Nov 2001, Benjamin Kosnik wrote:
> 
> >
> > > No, it's relevant to STABS, too.
> > > It's due to not properly searching virtual baseclasses.
> > > I might still have the changes to do that somewhere, if someone wants
> > > them.
> >
> > This has been broken for some time now. I'd appreciate it if it got
> > fixed, so that C++ could be debugged properly.
> I'm sure a lot of people would.
> Unfortunately, it appears I don't have the code i had worked up to
> abstract out the base class offset finding anymore.
> What's happening is that GDB wants to know the baseclass offset, and
> the routine it uses is tuned to either gnu-v2 or hp aCC (it checks
> for something only hp's debug readers fill in, and if it doesn't find
> it, it assumes gnu-v2), and the gnu-v2 code either returns the wrong
> value (weird errors occur), or -1, which gives you "virtual baseclass
> botch"/attempts to deref int values as pointers.
> 
> baseclass_offset needs to be abstracted into the cp abi model, and all
> existing uses need to use it.

Could you clarify what symptom this fix you're discussing is supposed
to solve?  I thought it was the one I was working on, but
baseclass_offset actually does nothing ABI specific at all.

Meanwhile the problem that was most annoying me wasn't even covered by
the testsuite.  Patch and tests coming up in the next hour.

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

Re: c++ debugging hosed

[Daniel Berlin]

On Mon, 26 Nov 2001, Daniel Jacobowitz wrote:

> On Sun, Nov 25, 2001 at 03:29:08PM -0500, Daniel Berlin wrote:
> >
> >
> > On Sun, 25 Nov 2001, Benjamin Kosnik wrote:
> >
> > >
> > > > No, it's relevant to STABS, too.
> > > > It's due to not properly searching virtual baseclasses.
> > > > I might still have the changes to do that somewhere, if someone wants
> > > > them.
> > >
> > > This has been broken for some time now. I'd appreciate it if it got
> > > fixed, so that C++ could be debugged properly.
> > I'm sure a lot of people would.
> > Unfortunately, it appears I don't have the code i had worked up to
> > abstract out the base class offset finding anymore.
> > What's happening is that GDB wants to know the baseclass offset, and
> > the routine it uses is tuned to either gnu-v2 or hp aCC (it checks
> > for something only hp's debug readers fill in, and if it doesn't find
> > it, it assumes gnu-v2), and the gnu-v2 code either returns the wrong
> > value (weird errors occur), or -1, which gives you "virtual baseclass
> > botch"/attempts to deref int values as pointers.
> >
> > baseclass_offset needs to be abstracted into the cp abi model, and all
> > existing uses need to use it.
>
> Could you clarify what symptom this fix you're discussing is supposed
> to solve?
Not being able to print subobjects, etc.
>   I thought it was the one I was working on, but
> baseclass_offset actually does nothing ABI specific at all.
This would be incorrect for virtual base classes
Look at it again.
Also notice we call find_rt_base_offset for the HP ABI.
The reason is that baseclass offsets are *always* abi specific.


>
> Meanwhile the problem that was most annoying me wasn't even covered by
> the testsuite.  Patch and tests coming up in the next hour.
>
> --
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
>

Re: c++ debugging hosed

[Daniel Berlin]

On Mon, 26 Nov 2001, Daniel Jacobowitz wrote:

> On Sun, Nov 25, 2001 at 03:29:08PM -0500, Daniel Berlin wrote:
> >
> >
> > On Sun, 25 Nov 2001, Benjamin Kosnik wrote:
> >
> > >
> > > > No, it's relevant to STABS, too.
> > > > It's due to not properly searching virtual baseclasses.
> > > > I might still have the changes to do that somewhere, if someone wants
> > > > them.
> > >
> > > This has been broken for some time now. I'd appreciate it if it got
> > > fixed, so that C++ could be debugged properly.
> > I'm sure a lot of people would.
> > Unfortunately, it appears I don't have the code i had worked up to
> > abstract out the base class offset finding anymore.
> > What's happening is that GDB wants to know the baseclass offset, and
> > the routine it uses is tuned to either gnu-v2 or hp aCC (it checks
> > for something only hp's debug readers fill in, and if it doesn't find
> > it, it assumes gnu-v2), and the gnu-v2 code either returns the wrong
> > value (weird errors occur), or -1, which gives you "virtual baseclass
> > botch"/attempts to deref int values as pointers.
> >
> > baseclass_offset needs to be abstracted into the cp abi model, and all
> > existing uses need to use it.
>
> Could you clarify what symptom this fix you're discussing is supposed
> to solve?  I thought it was the one I was working on, but
> baseclass_offset actually does nothing ABI specific at all.

I'm also quite confused how you can say this after looking at it:
baseclass_offset:
...

      /* First look for the virtual baseclass pointer
         in the fields.  */
      for (i = n_baseclasses; i < len; i++)
        {
          if (vb_match (type, i, basetype))
            {
              CORE_ADDR addr
              = unpack_pointer (TYPE_FIELD_TYPE (type, i),
                                valaddr + (TYPE_FIELD_BITPOS (type, i) /
8));

              return addr - (LONGEST) address;
            }
        }

Then looking above it at vb_match.

It's, in fact, the most abi specific stuff still left for C++.


It happens to basically work for non-virtual classes, but it couldn't
possibly work for virtual baseclasses (IE even if you pulled some magic in gcc to make
it still output the things vb_match was looking for, it wouldn't work
anyway.).


baseclass offset finding is a fundamental piece of C++ support in gdb.
It's required for printing things, calling methods, etc.


--Dan

Re: c++ debugging hosed

[Daniel Jacobowitz]

On Mon, Nov 26, 2001 at 07:43:39PM -0500, Daniel Berlin wrote:
> 
> 
> On Mon, 26 Nov 2001, Daniel Jacobowitz wrote:
> > Could you clarify what symptom this fix you're discussing is supposed
> > to solve?
> Not being able to print subobjects, etc.

OK, I'm just printing objects right now :)

> >   I thought it was the one I was working on, but
> > baseclass_offset actually does nothing ABI specific at all.
> This would be incorrect for virtual base classes
> Look at it again.
> Also notice we call find_rt_base_offset for the HP ABI.
> The reason is that baseclass offsets are *always* abi specific.

(it's find_rt_vbase_offset)

OK, this isn't in baseclass_offset.  I assume you mean
search_struct_method or find_method_list.

I'll get back to this in a few days when I fix my current bug.

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

Re: c++ debugging hosed

[Daniel Jacobowitz]

On Mon, Nov 26, 2001 at 07:53:24PM -0500, Daniel Berlin wrote:
> Then looking above it at vb_match.
> 
> It's, in fact, the most abi specific stuff still left for C++.
> 
> 
> It happens to basically work for non-virtual classes, but it couldn't
> possibly work for virtual baseclasses (IE even if you pulled some magic in gcc to make
> it still output the things vb_match was looking for, it wouldn't work
> anyway.).
> 
> 
> baseclass offset finding is a fundamental piece of C++ support in gdb.
> It's required for printing things, calling methods, etc.

Yes.  But not, most of the time, through this function.

I agree that it needs to be fixed.  I'll be back here in a few days, I
expect.

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

Re: c++ debugging hosed

[Benjamin Kosnik]

Thanks for the analysis Daniel.

> I'm sure a lot of people would.

Yep.

Re: c++ debugging hosed

[Daniel Jacobowitz]

On Sun, Nov 25, 2001 at 03:29:08PM -0500, Daniel Berlin wrote:
> 
> 
> On Sun, 25 Nov 2001, Benjamin Kosnik wrote:
> 
> >
> > > No, it's relevant to STABS, too.
> > > It's due to not properly searching virtual baseclasses.
> > > I might still have the changes to do that somewhere, if someone wants
> > > them.
> >
> > This has been broken for some time now. I'd appreciate it if it got
> > fixed, so that C++ could be debugged properly.
> I'm sure a lot of people would.
> Unfortunately, it appears I don't have the code i had worked up to
> abstract out the base class offset finding anymore.
> What's happening is that GDB wants to know the baseclass offset, and
> the routine it uses is tuned to either gnu-v2 or hp aCC (it checks
> for something only hp's debug readers fill in, and if it doesn't find
> it, it assumes gnu-v2), and the gnu-v2 code either returns the wrong
> value (weird errors occur), or -1, which gives you "virtual baseclass
> botch"/attempts to deref int values as pointers.
> 
> baseclass_offset needs to be abstracted into the cp abi model, and all
> existing uses need to use it.

Could you clarify what symptom this fix you're discussing is supposed
to solve?  I thought it was the one I was working on, but
baseclass_offset actually does nothing ABI specific at all.

Meanwhile the problem that was most annoying me wasn't even covered by
the testsuite.  Patch and tests coming up in the next hour.

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

Re: c++ debugging hosed

[Daniel Berlin]

On Mon, 26 Nov 2001, Daniel Jacobowitz wrote:

> On Sun, Nov 25, 2001 at 03:29:08PM -0500, Daniel Berlin wrote:
> >
> >
> > On Sun, 25 Nov 2001, Benjamin Kosnik wrote:
> >
> > >
> > > > No, it's relevant to STABS, too.
> > > > It's due to not properly searching virtual baseclasses.
> > > > I might still have the changes to do that somewhere, if someone wants
> > > > them.
> > >
> > > This has been broken for some time now. I'd appreciate it if it got
> > > fixed, so that C++ could be debugged properly.
> > I'm sure a lot of people would.
> > Unfortunately, it appears I don't have the code i had worked up to
> > abstract out the base class offset finding anymore.
> > What's happening is that GDB wants to know the baseclass offset, and
> > the routine it uses is tuned to either gnu-v2 or hp aCC (it checks
> > for something only hp's debug readers fill in, and if it doesn't find
> > it, it assumes gnu-v2), and the gnu-v2 code either returns the wrong
> > value (weird errors occur), or -1, which gives you "virtual baseclass
> > botch"/attempts to deref int values as pointers.
> >
> > baseclass_offset needs to be abstracted into the cp abi model, and all
> > existing uses need to use it.
>
> Could you clarify what symptom this fix you're discussing is supposed
> to solve?
Not being able to print subobjects, etc.
>   I thought it was the one I was working on, but
> baseclass_offset actually does nothing ABI specific at all.
This would be incorrect for virtual base classes
Look at it again.
Also notice we call find_rt_base_offset for the HP ABI.
The reason is that baseclass offsets are *always* abi specific.


>
> Meanwhile the problem that was most annoying me wasn't even covered by
> the testsuite.  Patch and tests coming up in the next hour.
>
> --
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
>

Re: c++ debugging hosed

[Daniel Berlin]

On Mon, 26 Nov 2001, Daniel Jacobowitz wrote:

> On Sun, Nov 25, 2001 at 03:29:08PM -0500, Daniel Berlin wrote:
> >
> >
> > On Sun, 25 Nov 2001, Benjamin Kosnik wrote:
> >
> > >
> > > > No, it's relevant to STABS, too.
> > > > It's due to not properly searching virtual baseclasses.
> > > > I might still have the changes to do that somewhere, if someone wants
> > > > them.
> > >
> > > This has been broken for some time now. I'd appreciate it if it got
> > > fixed, so that C++ could be debugged properly.
> > I'm sure a lot of people would.
> > Unfortunately, it appears I don't have the code i had worked up to
> > abstract out the base class offset finding anymore.
> > What's happening is that GDB wants to know the baseclass offset, and
> > the routine it uses is tuned to either gnu-v2 or hp aCC (it checks
> > for something only hp's debug readers fill in, and if it doesn't find
> > it, it assumes gnu-v2), and the gnu-v2 code either returns the wrong
> > value (weird errors occur), or -1, which gives you "virtual baseclass
> > botch"/attempts to deref int values as pointers.
> >
> > baseclass_offset needs to be abstracted into the cp abi model, and all
> > existing uses need to use it.
>
> Could you clarify what symptom this fix you're discussing is supposed
> to solve?  I thought it was the one I was working on, but
> baseclass_offset actually does nothing ABI specific at all.

I'm also quite confused how you can say this after looking at it:
baseclass_offset:
...

      /* First look for the virtual baseclass pointer
         in the fields.  */
      for (i = n_baseclasses; i < len; i++)
        {
          if (vb_match (type, i, basetype))
            {
              CORE_ADDR addr
              = unpack_pointer (TYPE_FIELD_TYPE (type, i),
                                valaddr + (TYPE_FIELD_BITPOS (type, i) /
8));

              return addr - (LONGEST) address;
            }
        }

Then looking above it at vb_match.

It's, in fact, the most abi specific stuff still left for C++.


It happens to basically work for non-virtual classes, but it couldn't
possibly work for virtual baseclasses (IE even if you pulled some magic in gcc to make
it still output the things vb_match was looking for, it wouldn't work
anyway.).


baseclass offset finding is a fundamental piece of C++ support in gdb.
It's required for printing things, calling methods, etc.


--Dan

Re: c++ debugging hosed

[Daniel Jacobowitz]

On Mon, Nov 26, 2001 at 07:43:39PM -0500, Daniel Berlin wrote:
> 
> 
> On Mon, 26 Nov 2001, Daniel Jacobowitz wrote:
> > Could you clarify what symptom this fix you're discussing is supposed
> > to solve?
> Not being able to print subobjects, etc.

OK, I'm just printing objects right now :)

> >   I thought it was the one I was working on, but
> > baseclass_offset actually does nothing ABI specific at all.
> This would be incorrect for virtual base classes
> Look at it again.
> Also notice we call find_rt_base_offset for the HP ABI.
> The reason is that baseclass offsets are *always* abi specific.

(it's find_rt_vbase_offset)

OK, this isn't in baseclass_offset.  I assume you mean
search_struct_method or find_method_list.

I'll get back to this in a few days when I fix my current bug.

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

Re: c++ debugging hosed

[Daniel Jacobowitz]

On Mon, Nov 26, 2001 at 07:53:24PM -0500, Daniel Berlin wrote:
> Then looking above it at vb_match.
> 
> It's, in fact, the most abi specific stuff still left for C++.
> 
> 
> It happens to basically work for non-virtual classes, but it couldn't
> possibly work for virtual baseclasses (IE even if you pulled some magic in gcc to make
> it still output the things vb_match was looking for, it wouldn't work
> anyway.).
> 
> 
> baseclass offset finding is a fundamental piece of C++ support in gdb.
> It's required for printing things, calling methods, etc.

Yes.  But not, most of the time, through this function.

I agree that it needs to be fixed.  I'll be back here in a few days, I
expect.

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