From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9509 invoked by alias); 8 Jan 2007 22:33:40 -0000 Received: (qmail 9500 invoked by uid 22791); 8 Jan 2007 22:33:39 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 08 Jan 2007 22:33:33 +0000 Received: from kahikatea.snap.net.nz (p202-124-120-214.snap.net.nz [202.124.120.214]) by viper.snap.net.nz (Postfix) with ESMTP id 7C9F83D8186; Tue, 9 Jan 2007 11:33:24 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 3E99E4F6E2; Tue, 9 Jan 2007 11:33:22 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17826.50865.340113.767106@kahikatea.snap.net.nz> Date: Mon, 08 Jan 2007 22:33:00 -0000 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: MI testsuite failures [PATCH] In-Reply-To: <20070108171149.GC15412@nevyn.them.org> References: <17825.33653.885121.321357@kahikatea.snap.net.nz> <17825.56391.466504.569955@kahikatea.snap.net.nz> <20070108171149.GC15412@nevyn.them.org> X-Mailer: VM 7.19 under Emacs 22.0.92.6 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: 2007-01/txt/msg00246.txt.bz2 > > Here's a patch with fixes for the testsuite. I've made a further change to > > varobj.c to fix a failure in mi-var-child.exp. > > Was this: > > FAIL: gdb.mi/mi-var-child.exp: update all vars int_ptr_ptr and children changed > FAIL: gdb.mi/mi-var-child.exp: update all vars struct_declarations.long_array.0 changed > > ? Certainly the second, which was to do with value == NULL and var->value != NULL. > The patch below fixes those, and this one too: > > FAIL: gdb.mi/mi-var-cmd.exp: assign same value to func (update) Yes, this looks right and is much simpler, but I just couldn't see how to do it. > I can't quite tell what your patch does, but I do see why these > failures happen. Because the var->updated and the var->value > previously NULL cases were not updating print_value, you sometimes had > to -var-update twice to get a value to leave the list. My patch defers the updating of the variable object until -var-update is issued. > This is the same reason you had to add spurious -var-update's to the > testsuite. I don't know that I'd call them spurious. The command -var-assign seems a bit anomalous to me. It could just set the value like "set var i=10". I think the updating of variable objects should be left to -var-update, but this change might be too radical at this stage. > The first time we do that it's a good thing, i.e. we want lpcharacter > to be listed now. The second time it's kind of dodgy: lpcharacter > is not a NULL terminated string and it just so happens that linteger > is right after lcharacter in memory, so -var-assign'ing to linteger > "changes" the string pointer to by lpcharacter. I think that's the best we can do; the `string' will be displayed differently in the watch window. > 2007-01-08 Daniel Jacobowitz > > * varobj.c (install_new_value): Always update print_value. > (value_get_print_value): Immediately return NULL for missing > values. > > 2007-01-08 Nick Roberts > Daniel Jacobowitz > > * gdb.mi/mi-var-cmd.exp: Expect lpcharacter to update when > lcharacter or linteger change. Correct duplicated test name. > * gdb.mi/mi2-var-cmd.exp: Likewise. Yes, I'd be happy to see these changes installed. -- Nick http://www.inet.net.nz/~nickrob