From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21649 invoked by alias); 10 Dec 2009 18:41:13 -0000 Received: (qmail 21641 invoked by uid 22791); 10 Dec 2009 18:41:12 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 10 Dec 2009 18:41:05 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id C97CF10D91; Thu, 10 Dec 2009 18:41:03 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id B27A21078C; Thu, 10 Dec 2009 18:41:03 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1NInwl-0004Ry-0k; Thu, 10 Dec 2009 13:41:03 -0500 Date: Thu, 10 Dec 2009 18:41:00 -0000 From: Daniel Jacobowitz To: Chris Moller Cc: gdb-patches@sourceware.org Subject: Re: Patch for PR 9399 Message-ID: <20091210184102.GA16828@caradoc.them.org> Mail-Followup-To: Chris Moller , gdb-patches@sourceware.org References: <4B1FA6F2.1060105@redhat.com> <20091209140534.GA12330@caradoc.them.org> <4B1FBDF4.4040801@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1FBDF4.4040801@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-12/txt/msg00145.txt.bz2 Tom's approved this. That's fine. But for posterity: On Wed, Dec 09, 2009 at 10:10:44AM -0500, Chris Moller wrote: > >>You can see what the patch does by compiling -g virtfunc.cc, gdb-ing > >>it, breaking in the return stmt at // marker1, and doing things like > >>"print o.do_print()". Without the patch, gdb tries to access > >>location 0x0; with the patch it does the right thing. (There are > >>more tests in virtfunc2.exp) > >> > > > >Where does the access to 0x0 come from? Is it inside > >search_struct_field? > > Ultimately, yes. Without the patch, the thread ultimately gets to > > if (BASETYPE_VIA_VIRTUAL (type, i)) > > in search_struct_field and then to the memcpy about 30 lines later > that extracts a new value struct. That main_type of that value > doesn't include a field for the virtual function, so it's never > found, and ultimately returns a null pointer. I haven't a clue why > it works that way--for a while I was working on the assumption that > the DWARF reader was screwing up, but if it is, it's too subtle for > me. I couldn't follow this and haven't had time to debug it myself yet. But we shouldn't dereference any null (target) pointers in this. If we do, there's a bug in some routine this function calls. > > I wouldn't expect value_cast_structs to do any > >cast in this case, > > value_cast_structs only does nothing if both TYPE_NAME()s are null. > I was wondering if, back when the code was originally written, if > there never was a case when both TYPE_NAME()s were non-null--it's the > only way, other than simple oversight, I can account for that case > not being covered. No, it looks exactly like I intended. If we have two classes, we check if A is a base class of B, then if B is a base class of A. If A == B, neither of those checks will be true, and we'll return without doing anything. So the problem is that one of those base class checks is calling error(). That's not supposed to happen. -- Daniel Jacobowitz CodeSourcery