From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16249 invoked by alias); 27 Nov 2001 00:43:51 -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 16159 invoked from network); 27 Nov 2001 00:43:50 -0000 Received: from unknown (HELO www.cgsoftware.com) (208.155.65.221) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 00:43:50 -0000 Received: from localhost (localhost [127.0.0.1]) by www.cgsoftware.com (8.9.3/8.9.3) with ESMTP id TAA23485; Mon, 26 Nov 2001 19:43:39 -0500 Date: Thu, 15 Nov 2001 08:48:00 -0000 From: Daniel Berlin To: Daniel Jacobowitz cc: Benjamin Kosnik , Eli Zaretskii , , , Subject: Re: c++ debugging hosed In-Reply-To: <20011126183836.A9099@nevyn.them.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2001-11/txt/msg00160.txt.bz2 Message-ID: <20011115084800.21Ul1VeIsclds2UwVucoMEV1SdVchQnzJl6JOzBJu5I@z> 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 >