This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: crasher in C++ ABI code
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Michael Snyder <msnyder at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com, jimb at redhat dot com
- Date: Thu, 12 Sep 2002 20:35:06 -0400
- Subject: Re: crasher in C++ ABI code
- References: <3D812FF4.8BA9C266@redhat.com>
On Thu, Sep 12, 2002 at 05:23:16PM -0700, Michael Snyder wrote:
> Attention, all you c++_abi_savvy folk...
>
> I found a crasher bug while running the gdb testsuite on a COFF
> toolchain. TYPE_VPTR_FIELDNO returned -1; I haven't looked into
> this mechanism, but I assume that's a mistake. When it was applied
> via value_field, of course it yielded a garbage value.
>
> So looking at coffread.c, I see that there are no references
> to vptr_fieldno nor vptr_basetype -- these fields are never
> initialized.
They're initialized in alloc_type to -1... and further by stabs and
dwarf2.
> I'm just wondering where to go from here. Is it possible to
> obtain these values from COFF? If not, perhaps their access
> methods should check for an invalid value?
COFF is not the issue. coffread is just like elfread; it's an object
file reader. The question is where your debug information comes from.
Mdebug? Stabs? DWARF-2? If it's real mdebug instead of
stabs-in-mdebug, you're squat out of luck for C++.
Also, TYPE_VPTR_FIELDNO is often -1 by design; see
fill_in_vptr_fieldno and the comment above it.
- Is fill_in_vptr_fieldno getting called?
- If it were called would it succeed?
- Probably its return value needs to be checked somewhere.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer