From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15385 invoked by alias); 25 Nov 2001 16:34:30 -0000 Mailing-List: contact gdb-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 15232 invoked from network); 25 Nov 2001 16:34:28 -0000 Received: from unknown (HELO www.cgsoftware.com) (208.155.65.221) by sourceware.cygnus.com with SMTP; 25 Nov 2001 16:34:28 -0000 Received: from localhost (localhost [127.0.0.1]) by www.cgsoftware.com (8.9.3/8.9.3) with ESMTP id LAA29734; Sun, 25 Nov 2001 11:34:19 -0500 Date: Mon, 12 Nov 2001 11:29:00 -0000 From: Daniel Berlin To: Eli Zaretskii cc: , , , Subject: Re: c++ debugging hosed In-Reply-To: <200111250923.LAA04147@is.elta.co.il> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2001-11/txt/msg00128.txt.bz2 On Sun, 25 Nov 2001, Eli Zaretskii wrote: > > From: Jason Merrill > > Date: Wed, 14 Nov 2001 16:02:11 +0000 > > > > > --with-dwarf2: > > > (gdb) p *this > > > can't find class named `std::basic_filebuf >', 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