From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10628 invoked by alias); 5 Jul 2013 14:03:39 -0000 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 Received: (qmail 10593 invoked by uid 89); 5 Jul 2013 14:03:33 -0000 X-Spam-SWARE-Status: No, score=-7.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 05 Jul 2013 14:03:29 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r65E3REF025839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Jul 2013 10:03:28 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r65E3QId028412; Fri, 5 Jul 2013 10:03:27 -0400 Message-ID: <51D6D22E.2030807@redhat.com> Date: Fri, 05 Jul 2013 14:03:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andrew Burgess CC: "gdb-patches@sourceware.org" Subject: Re: [PATCH] optimized out registers in mi References: <51D6C9D8.4000502@broadcom.com> In-Reply-To: <51D6C9D8.4000502@broadcom.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-07/txt/msg00194.txt.bz2 On 07/05/2013 02:27 PM, Andrew Burgess wrote: > [1] I applied a patch yesterday that changed value_optimized_out, > before I applied yesterdays patch the behaviour of -data-list-registers > was a bit random, if the register value was lazy then you would get > the "" result, if the value was not lazy then you got > the error. Of the two behaviours I think returning the > "" string is by far the most helpful so that's > the behaviour we now get in all cases. Agreed. It'd be nice to handle partially optimized out registers too, though I'm not sure gcc does something like that currently. And that can be always handled later. This is already a good step. > gdb/ChangeLog > - if (format == 'N') > + /* Displaying optimized out values using anything other than the default > + format will result in the value 0 being shown. */ Please make that s/will/would/. It's confusing as is; it made me think that printing 0 was what the patch was meaning to do. But, this looks hacky to me. Do we print 0 with the CLI as well? If not, what's handling it that's missing in MI? Isn't this being handled gracefully somewhere within val_print itself (I'd think in val_print_scalar_formatted)? -- Pedro Alves