From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12156 invoked by alias); 5 Dec 2006 22:27:19 -0000 Received: (qmail 12146 invoked by uid 22791); 5 Dec 2006 22:27:18 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 05 Dec 2006 22:27:13 +0000 Received: (qmail 15012 invoked from network); 5 Dec 2006 22:27:11 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Dec 2006 22:27:11 -0000 To: Nick Roberts Cc: Vladimir Prus , gdb-patches@sources.redhat.com, Vladimir Prus Subject: Re: MI: fix base members in references 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> <20061205214654.GA29947@nevyn.them.org> From: Jim Blandy Date: Tue, 05 Dec 2006 22:27:00 -0000 In-Reply-To: <20061205214654.GA29947@nevyn.them.org> (Daniel Jacobowitz's message of "Tue, 5 Dec 2006 16:46:54 -0500") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00052.txt.bz2 Daniel Jacobowitz writes: > 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? :-) *blush* (ding) Gnus is amazingly slow at finding parent messages. >> 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. Oh, yes --- I meant to drop the TYPE_CODE_REF case.