From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4394 invoked by alias); 19 Jul 2011 16:13:38 -0000 Received: (qmail 4383 invoked by uid 22791); 19 Jul 2011 16:13:37 -0000 X-SWARE-Spam-Status: No, hits=-7.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Jul 2011 16:13:19 +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 p6JGDJYW002094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 19 Jul 2011 12:13:19 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p6JGDJmK025788; Tue, 19 Jul 2011 12:13:19 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p6JGDHug006384; Tue, 19 Jul 2011 12:13:18 -0400 From: Tom Tromey To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [RFC 06/12] entryval: Display @entry parameters in bt full References: <20110718201852.GG30496@host1.jankratochvil.net> Date: Tue, 19 Jul 2011 16:21:00 -0000 In-Reply-To: <20110718201852.GG30496@host1.jankratochvil.net> (Jan Kratochvil's message of "Mon, 18 Jul 2011 22:18:53 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: 2011-07/txt/msg00472.txt.bz2 >>>>> "Jan" == Jan Kratochvil writes: Jan> p@entry is not particularly useful here because the `line' local Jan> variable contains the same. One can imagine in other real world Jan> applications it can be useful - for a backtrace sent by user where Jan> you do not have a reproducer and/or the core file (the case of ABRT Jan> bugreports). Jan> The parameter@entry lines are not displayed if they are not useful. Jan> Therefore if they would display the same value as the current Jan> parameter value or if GDB cannot successfully determine the entry Jan> value. Jan> It is displayed by `bt full' and `info args'. RFC is whether it is Jan> not too verbose and/or if it should not be displayed some way even Jan> with normal `bt'. Also whether there should be some `set' variable Jan> to forget about @entry values. I think it is often confusing to users to see the currently value in a backtrace. Certainly this has confused me any number of times. My first thought is to display this information by default in the backtrace, even in the short form. However, then I think there is another possible confusion -- some arguments may have entry values, and some may not; and I think it would be nice to clearly distinguish this for users. How about something like: #8 0x000000000048c50d in execute_command (p=0x22b573b "" (p@entry=0x22b5720 "maintenance internal-error "), from_tty=1) at top.c:438 Here, the entry value is clearly distinguished and arguments lacking an entry value are also immediately visible. If this is too verbose for somebody, let them complain and we can add a new parameter. If you think it is important to also distinguish the case where the argument is equal to its entry value, then we can add additional output sugar for that, e.g.: #8 0x000000000048c50d in execute_command (p=p@entry=0x22b573b "whatever", from_tty=1) at top.c:438 Tom