gdb crash when printing C++ class

gdb crash when printing C++ class

[Kris Warkentin]

Some background:

I'm using Intel's icc compiler with Dinkum C++ headers.  I have a 
feeling that there is something wrong with the way the debug info is 
being generated but I want to understand the issue a bit better before I 
send it off to them.

In gnuv3_baseclass_offset there is a section of code described by this 
comment:

  /* We're now looking for the cur_base_offset'th entry (negative index)
     in the vcall_and_vbase_offsets array.  We used to cast the object to
     its TYPE_VPTR_BASETYPE, and reference the vtable as TYPE_VPTR_FIELDNO;
     however, that cast can not be done without calling baseclass_offset 
again
     if the TYPE_VPTR_BASETYPE is a virtual base class, as described in the
     v3 C++ ABI Section 2.4.I.2.b.  Fortunately the ABI guarantees that the
     vtable pointer will be located at the beginning of the object, so 
we can
     bypass the casting.  Verify that the TYPE_VPTR_FIELDNO is in fact 
at the
     start of whichever baseclass it resides in, as a sanity measure - iff
     we have debugging information for that baseclass.  */

  vbasetype = TYPE_VPTR_BASETYPE (type);
  if (TYPE_VPTR_FIELDNO (vbasetype) < 0)
    fill_in_vptr_fieldno (vbasetype);

When I try to print an ostream variable, gdb crashes because vbasetype 
is dereferenced when type->main_type->vptr_basetype is null.  In fact, 
TYPE_VPTR_FIELDNO(type) is -1 so as one of my tests, I tried calling 
fill_in_vptr_fieldno(type) but that didn't fill it in.

As a workaround to prevent the crash, I just return -1 if 
TYPE_VPTR_BASETYPE(type) is null and then I get something like this:

10              ostream foo;
(gdb) p foo
$1 = {
  <std::basic_ios<char, std::char_traits<char> >> = <invalid address>,
  members of std::ostream:
  _vptr.basic_ostream<char, std::char_traits<char> > = void
}

Using gcc with very similar headers, I get much nicer output:

10              ostream foo;
(gdb) p foo
$6 = {
  <std::basic_ios<char, std::char_traits<char> >> = {
    <> = {<No data fields>},
    members of std::basic_ios<char, std::char_traits<char> >:
    _Mystrbuf = 0x0,
    _Tiestr = 0x0,
    _Fillch = 32 ' '
  },
  members of std::ostream:
  _vptr.basic_ostream = 0x804f38c
}

Where was the vptr_basetype set up in the first place?  Since type 
claims to have a baseclass, logically the baseclass pointer shouldn't be 
void so I'm assuming it just didn't get filled in somewhere.  Can anyone 
give me any hints on how to determine if Intel's debug info is off?

cheers,

Kris

Re: gdb crash when printing C++ class

[Daniel Jacobowitz]

On Fri, Dec 10, 2004 at 03:03:35PM -0500, Kris Warkentin wrote:
> Where was the vptr_basetype set up in the first place?  Since type 

Take a look at the dwarf2 reader.  TYPE_VPTR_BASETYPE.

> claims to have a baseclass, logically the baseclass pointer shouldn't be 
> void so I'm assuming it just didn't get filled in somewhere.  Can anyone 
> give me any hints on how to determine if Intel's debug info is off?

It's probably not wrong, just different.  Please show an example
(readelf -wi will dump it).

-- 
Daniel Jacobowitz

Re: gdb crash when printing C++ class

[Kris Warkentin]

I compared the vptr entries in the readelf -wi output from gcc vs. icc 
and they're certainly different.  I sent the gcc vs. icc output files to 
Daniel directly - a little too big for the mailing list.  If anyone else 
wants them, let me know.  My knowledge isn't deep enough to tell which 
differences are significant.

I set a breakpoint in dwarf2read.c at the point where the vptr basetype 
is set and what do you know?  With the icc generated code, it's never 
hit.  I've got the dwarf-2 specification printed out here...I guess I'm 
going to have to figure out what the heck a DIE is and all the other 
stuff I wish I didn't need to know. ;-)

cheers,

Kris


Daniel Jacobowitz wrote:

>On Fri, Dec 10, 2004 at 03:03:35PM -0500, Kris Warkentin wrote:
>  
>
>>Where was the vptr_basetype set up in the first place?  Since type 
>>    
>>
>
>Take a look at the dwarf2 reader.  TYPE_VPTR_BASETYPE.
>
>  
>
>>claims to have a baseclass, logically the baseclass pointer shouldn't be 
>>void so I'm assuming it just didn't get filled in somewhere.  Can anyone 
>>give me any hints on how to determine if Intel's debug info is off?
>>    
>>
>
>It's probably not wrong, just different.  Please show an example
>(readelf -wi will dump it).
>
>  
>

Re: gdb crash when printing C++ class

[Daniel Jacobowitz]

On Fri, Dec 10, 2004 at 04:26:31PM -0500, Kris Warkentin wrote:
> I compared the vptr entries in the readelf -wi output from gcc vs. icc 
> and they're certainly different.  I don't have enough understanding yet 
> to know what differences are signifigant but hopefully looking at the 
> dwarf2 reader will enlighten me.  I've attached the readelf output just 
> in case someone wants to take a look for anything obvious.  Thanks.

GNU's use of DW_AT_containing_type for this is somewhat nonstandard. 
You'll have to find another way to work out where the vptr is for the
ICC output.  You may want to do it by the C++ ABI rather than by the
debug info.

-- 
Daniel Jacobowitz