Message ID | 1398665538-16580-3-git-send-email-yao@codesourcery.com |
---|---|
State | Committed |
Headers |
Return-Path: <x14314964@homiemail-mx20.g.dreamhost.com> X-Original-To: siddhesh@wilcox.dreamhost.com Delivered-To: siddhesh@wilcox.dreamhost.com Received: from homiemail-mx20.g.dreamhost.com (mx2.sub5.homie.mail.dreamhost.com [208.113.200.128]) by wilcox.dreamhost.com (Postfix) with ESMTP id 80CD036007A for <siddhesh@wilcox.dreamhost.com>; Sun, 27 Apr 2014 23:15:53 -0700 (PDT) Received: by homiemail-mx20.g.dreamhost.com (Postfix, from userid 14314964) id 3FC4541449A57; Sun, 27 Apr 2014 23:15:53 -0700 (PDT) X-Original-To: gdb@patchwork.siddhesh.in Delivered-To: x14314964@homiemail-mx20.g.dreamhost.com Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by homiemail-mx20.g.dreamhost.com (Postfix) with ESMTPS id 1FB9841449A56 for <gdb@patchwork.siddhesh.in>; Sun, 27 Apr 2014 23:15:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; q=dns; s=default; b=V2c2M vIjRAjYVr40422ZXiKlpyb3GRF1F8YwST245Xzgp4dMrf12jJ+dlZ+5wCGUcx/Er 8MJQlC7C7oE7JVDGKMqXiSey2BvStNJc+o3qGGZ4y6iWS0a4UrGHLnqHaJ7NuBrD ZGz6keWTqJH9fQm/RO9+7+mGVwnxABhc7HLBNE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; s=default; bh=zz8tkDJITLK siHHMZOnqHc+koxE=; b=CZxtz+10/wcAubnEcmBjP0+X4MAr8lHSSFjjQJZzJn2 eMjvPgx+WKniHBkFRPsyn0LOvdZxkZ24wQolzyA+NRI++TvHW7siKYQWk5wLKx5S gdpH50Kg7VoNurALV/fQVvbfXAowXGJePAeklPZ8bwWGTdjfGrHHavTE3K7HG4NU = Received: (qmail 18772 invoked by alias); 28 Apr 2014 06:15:21 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-gdb=patchwork.siddhesh.in@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 18677 invoked by uid 89); 28 Apr 2014 06:15:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL, BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 28 Apr 2014 06:15:19 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1WeeqR-0005uM-TB from Yao_Qi@mentor.com for gdb-patches@sourceware.org; Sun, 27 Apr 2014 23:15:15 -0700 Received: from SVR-ORW-FEM-02.mgc.mentorg.com ([147.34.96.206]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Apr 2014 23:15:15 -0700 Received: from qiyao.dyndns.org.com (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.2.247.3; Sun, 27 Apr 2014 23:15:14 -0700 From: Yao Qi <yao@codesourcery.com> To: <gdb-patches@sourceware.org> Subject: [PATCH 2/4] Show new created display Date: Mon, 28 Apr 2014 14:12:16 +0800 Message-ID: <1398665538-16580-3-git-send-email-yao@codesourcery.com> In-Reply-To: <1398665538-16580-1-git-send-email-yao@codesourcery.com> References: <1398665538-16580-1-git-send-email-yao@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-DH-Original-To: gdb@patchwork.siddhesh.in |
Commit Message
Yao Qi
April 28, 2014, 6:12 a.m. UTC
When I run refactored unavailable.exp, I find command display behaves a little different on live inferior and on examining traceframes. In live inferior, when command "display argc" is typed, the value of "argc" is shown. (gdb) display argc 1: argc = 1 '\001' however, on tfile target, when command "display argc" is typed, the value of "argc" is not shown. (gdb) tfind Found trace frame 0, tracepoint 1 at ../../../../git/gdb/testsuite/gdb.trace/unavailable.cc:198 198 i = (int) argc + argi + argf + argd + argstruct.memberi + argarray[1]; (gdb) display argc I also notice that on "core" target, the value of "argc" isn't shown either. This difference is caused by the code below in printcmd.c:display_command, if (from_tty && target_has_execution) do_one_display (new); Looks the value of each display is shown if the target has execution. Source code archaeology doesn't tell much about this requirement. However, if we type command "display" then on "core" or "tfile" target, the value of "argc" is still displayed, for "core" target, (gdb) display argc (gdb) display 1: argc = 1 '\001' for "tfile" target, (gdb) display argc (gdb) display 1: argc = <unavailable> I feel that it is not necessary to have such "target has execution" requirement to show the value of new created display. Auto-display is a feature to show the value of expression frequently, has nothing to do with whether target has execution or not. On the other hand, GDB has the requirement for new created display, but command "display" can still show them, this is an inconsistency, which should be fixed. This patch is to remove the checking to target_has_execution from the condition. gdb: 2014-04-26 Yao Qi <yao@codesourcery.com> * printcmd.c (display_command): Remove the check to target_has_execution. --- gdb/printcmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On 04/28/2014 07:12 AM, Yao Qi wrote: > When I run refactored unavailable.exp, I find > command display behaves a little different on live inferior and on > examining traceframes. In live inferior, when command "display argc" > is typed, the value of "argc" is shown. > > (gdb) display argc > 1: argc = 1 '\001' > > however, on tfile target, when command "display argc" is typed, the > value of "argc" is not shown. > > (gdb) tfind > Found trace frame 0, tracepoint 1 > at ../../../../git/gdb/testsuite/gdb.trace/unavailable.cc:198 > 198 i = (int) argc + argi + argf + argd + argstruct.memberi + argarray[1]; > (gdb) display argc > > I also notice that on "core" target, the value of "argc" isn't shown > either. This difference is caused by the code below in printcmd.c:display_command, > > if (from_tty && target_has_execution) > do_one_display (new); > > Looks the value of each display is shown if the target has execution. > Source code archaeology doesn't tell much about this requirement. > However, if we type command "display" then on "core" or "tfile" > target, the value of "argc" is still displayed, Maybe ancient, ancient code that tried to prevent "display $pc" from erroring out? Judging from doing that when there's execution, and then killing the inferior, and getting: (gdb) display 1: $pc = <error: No registers.> Looks like we handle errors fine here, so I see no issue. I assume that if there's no target pushed yet, we'll now see that error -- it's fine with me. It would be good if display.exp itself was augmented to explicitly test this. Say, do "display global" (where global is a variable that is initialized to something not zero), and also "display $pc" before there's execution. > This patch is to remove the checking to target_has_execution from the > condition. OK.
diff --git a/gdb/printcmd.c b/gdb/printcmd.c index 87b1448..228d4ad 100644 --- a/gdb/printcmd.c +++ b/gdb/printcmd.c @@ -1547,7 +1547,7 @@ display_command (char *arg, int from_tty) new->enabled_p = 1; display_chain = new; - if (from_tty && target_has_execution) + if (from_tty) do_one_display (new); dont_repeat ();