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: Michael Snyder <msnyder at redhat dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: gdb-patches at sources dot redhat dot com, jimb at redhat dot com
- Date: Thu, 12 Sep 2002 18:02:11 -0700
- Subject: Re: crasher in C++ ABI code
- Organization: Red Hat, Inc.
- References: <3D812FF4.8BA9C266@redhat.com> <20020913003506.GA19479@nevyn.them.org>
Daniel Jacobowitz wrote:
>
> 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.
Yes, I've found it, I'm about to submit a patch.