From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5448 invoked by alias); 24 Mar 2006 03:03:37 -0000 Received: (qmail 5437 invoked by uid 22791); 24 Mar 2006 03:03:36 -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; Fri, 24 Mar 2006 03:03:34 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FMcaK-0000yA-M2 for gdb-patches@sourceware.org; Thu, 23 Mar 2006 22:03:32 -0500 Date: Fri, 24 Mar 2006 04:30:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: Re: MI: type prefixes for values Message-ID: <20060324030332.GB2853@nevyn.them.org> Mail-Followup-To: gdb-patches@sourceware.org References: <17427.54333.236860.258115@kahikatea.snap.net.nz> <20060317191207.GA19068@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00262.txt.bz2 On Mon, Mar 20, 2006 at 09:40:49AM +0300, Vladimir Prus wrote: > > On Fri, Mar 17, 2006 at 07:07:17PM +0300, Vladimir Prus wrote: > >> Nick Roberts wrote: > >> > >> > 2006-03-12 Nick Roberts > >> > > >> > * mi/mi-cmd-stack.c (list_args_or_locals): Use common_val_print > >> > instead of print_variable_value so that type doesn't get printed > >> > with value. > >> > >> This patch is much more important that value formatting, in fact. Without > >> it, if there's local reference variable that's no initialized, we get > >> this output from gdb: > >> > >> (gdb) -stack-list-locals --all-values > >> Cannot access memory at address 0x1 > >> ^error,msg="Cannot access memory at address 0x1" > >> > >> Essentially, I can't see any local variables. This patch fixes this too, > >> because, I believe, common_val_print does check for non-dereferencable > >> values. Changelogs say common_val_print was specifically added for this > >> purpose. > > > > Did you try this? > > Yes, I did. I got the above error without the patch, with CVS HEAD state. I > got the list of local variables, on the same testcase, with CVS HEAD + > patch. OK, I checked this out. Before, if all the variables are initialized: ^done,locals=[{name="baz",value="2"},{name="blaz2",value="(int &) @0x5009c8: 1"}, {name="blaz4",value="(int &) @0x5009c8: 1"}, {name="blaz",value="(int &) @0x5009c8: 1"}, {name="blaz3",value="(int &) @0x5009c8: 1"}, {name="blaz5",value="(int &) @0x5009c8: 1"}] If they aren't: &"Cannot access memory at address 0x0\n" ^error,msg="Cannot access memory at address 0x0" After: ^done,locals=[{name="baz",value="10922"},{name="blaz2",value="@0x2aaaaabc1ca0"}, {name="blaz4",value="@0x4005e0"},{name="blaz",value="@0x0"}, {name="blaz3",value="@0x40041b"},{name="blaz5",value="@0x400578"}] Now we are showing only the reference, not the target. I would have expected the target value. Looking at Eclipse: cdi/org/eclipse/cdt/debug/mi/core/cdi/model/type/IntegralValue.java // Coming from a reference if (valueString.startsWith("@")) { //$NON-NLS-1$ valueString = valueString.substring(1); int colon = valueString.indexOf(':'); if (colon != -1) { valueString = valueString.substring(colon + 1); } } else { It wants to show the value in its variables window, not the reference. So this patch would break it. So, should we change common_val_print, do you think? -- Daniel Jacobowitz CodeSourcery