From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24322 invoked by alias); 6 Dec 2006 09:04:15 -0000 Received: (qmail 24307 invoked by uid 22791); 6 Dec 2006 09:04:13 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 06 Dec 2006 09:04:02 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Grsgx-0003qf-23 for gdb-patches@sources.redhat.com; Wed, 06 Dec 2006 10:03:51 +0100 Received: from 73-198.umostel.ru ([82.179.73.198]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Dec 2006 10:03:51 +0100 Received: from ghost by 73-198.umostel.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Dec 2006 10:03:51 +0100 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: MI: fix base members in references Date: Wed, 06 Dec 2006 09:04:00 -0000 Message-ID: References: <200611291555.42209.ghost@cs.msu.su> <20061205204447.GC25572@nevyn.them.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1559082.yuv1i4tm7I" Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.2 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: 2006-12/txt/msg00060.txt.bz2 --nextPart1559082.yuv1i4tm7I Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8Bit Content-length: 759 Daniel Jacobowitz wrote: > On Wed, Nov 29, 2006 at 03:55:42PM +0300, Vladimir Prus wrote: >> The attached patch fixed the problem, no regression. I'll write a >> testcase for it as soon as my previous references patch is reviewed -- I >> don't want to pile too many testcases in as-yet-uncommitted file. >> >> OK? > > OK, with a changelog entry. Thanks, attached is the version with changelog entry that I've committed. >> If this patch is fine, can I also commit it to 6.6 branch? The bug in >> question is quite problematic for C++ code. > > Sounds fine to me, but check with Joel. I'll check. After (and if) this patch is merged to branch, and my other references patch is checked in, I'll adjust the code to just assert, as discussed. - Volodya --nextPart1559082.yuv1i4tm7I Content-Type: text/x-diff; name="base_references_final.diff" Content-Transfer-Encoding: 8Bit Content-Disposition: attachment; filename="base_references_final.diff" Content-length: 1304 Index: ChangeLog =================================================================== RCS file: /cvs/src/src/gdb/ChangeLog,v retrieving revision 1.8008 diff -u -p -r1.8008 ChangeLog --- ChangeLog 6 Dec 2006 06:51:48 -0000 1.8008 +++ ChangeLog 6 Dec 2006 09:01:09 -0000 @@ -1,3 +1,8 @@ +2006-12-06 Vladimir Prus + + * varobj.c (cplus_value_of_child): When accessing + base suboject, don't specially process references. + 2006-12-05 Adam Nemet * MAINTAINERS (Write After Approval): Add myself. Index: varobj.c =================================================================== RCS file: /cvs/src/src/gdb/varobj.c,v retrieving revision 1.62 diff -u -p -r1.62 varobj.c --- varobj.c 29 Nov 2006 06:41:13 -0000 1.62 +++ varobj.c 6 Dec 2006 09:01:10 -0000 @@ -2428,8 +2428,9 @@ cplus_value_of_child (struct varobj *par { struct value *temp = NULL; - if (TYPE_CODE (value_type (parent->value)) == TYPE_CODE_PTR - || TYPE_CODE (value_type (parent->value)) == TYPE_CODE_REF) + /* No special processing for references is needed -- + value_cast below handles references. */ + if (TYPE_CODE (value_type (parent->value)) == TYPE_CODE_PTR) { if (!gdb_value_ind (parent->value, &temp)) return NULL; --nextPart1559082.yuv1i4tm7I--