From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14737 invoked by alias); 5 Dec 2006 21:47:09 -0000 Received: (qmail 14729 invoked by uid 22791); 5 Dec 2006 21:47:09 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 05 Dec 2006 21:47:03 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1Gri7q-0007pZ-Qp; Tue, 05 Dec 2006 16:46:54 -0500 Date: Tue, 05 Dec 2006 21:47:00 -0000 From: Daniel Jacobowitz To: Nick Roberts , Jim Blandy Cc: Vladimir Prus , gdb-patches@sources.redhat.com, Vladimir Prus Subject: Re: MI: fix base members in references Message-ID: <20061205214654.GA29947@nevyn.them.org> Mail-Followup-To: Nick Roberts , Jim Blandy , Vladimir Prus , gdb-patches@sources.redhat.com, Vladimir Prus References: <200611291555.42209.ghost@cs.msu.su> <17781.56458.807690.396014@kahikatea.snap.net.nz> <20061205211214.GA28333@nevyn.them.org> <17781.58050.562000.498586@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17781.58050.562000.498586@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.13 (2006-08-11) 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/msg00048.txt.bz2 On Wed, Dec 06, 2006 at 10:21:06AM +1300, Nick Roberts wrote: > The comment in varobj.c refers to "Baseclass" and I presume the original author > included the case > > TYPE_CODE (value_type (parent->value)) == TYPE_CODE_REF > > for a specific reason. Probably, but as Vlad's explanation is correct, either the original author was wrong or the behavior of value_ind has changed. Something in this code should change, but see below. On Tue, Dec 05, 2006 at 01:33:12PM -0800, Jim Blandy wrote: > (By the way --- it's handy to include a link to the post with the > patch, or ideally the patch itself.) Is a threading mailer really so much to ask? :-) > How should this behave if parent->value is a reference to a pointer? > Shouldn't it follow the ref, and then behave the same as when it's a > pointer? If so, then the fix would be something like this instead > (not that I understand this code): If this is always the same values affected by Vlad's other patch which calls coerce_ref when setting the value, then maybe we should just be asserting there is no reference here after that patch. > --- 2426,2439 ---- > /* Baseclass */ > if (parent->value != NULL) > { > ! struct value *temp = coerce_ref (parent->value); > > ! if (TYPE_CODE (value_type (temp)) == TYPE_CODE_PTR > ! || TYPE_CODE (value_type (temp)) == TYPE_CODE_REF) > { > ! if (!gdb_value_ind (temp, &temp)) > return NULL; In any case, you can drop the TYPE_CODE_REF check if you do it this way. -- Daniel Jacobowitz CodeSourcery