From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24947 invoked by alias); 19 Jul 2011 10:48:14 -0000 Received: (qmail 24933 invoked by uid 22791); 19 Jul 2011 10:48:13 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Jul 2011 10:47:49 +0000 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Qj7q8-0004nd-M9; Tue, 19 Jul 2011 06:47:48 -0400 Date: Tue, 19 Jul 2011 10:57:00 -0000 Message-Id: From: Eli Zaretskii To: Jan Kratochvil CC: gdb-patches@sourceware.org In-reply-to: <20110718201852.GG30496@host1.jankratochvil.net> (message from Jan Kratochvil on Mon, 18 Jul 2011 22:18:53 +0200) Subject: Re: [RFC 06/12] entryval: Display @entry parameters in bt full Reply-to: Eli Zaretskii References: <20110718201852.GG30496@host1.jankratochvil.net> 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: 2011-07/txt/msg00455.txt.bz2 > Date: Mon, 18 Jul 2011 22:18:53 +0200 > From: Jan Kratochvil > > this is a first kind of access to the entry values. A (non-testcase) demo is: > > #8 0x000000000048c50d in execute_command (p=0x22b573b "", from_tty=1) at top.c:438 > p@entry = 0x22b5720 "maintenance internal-error " > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > arg = > cleanup = 0x28333b0 > c = 0x24996d0 > flang = > warned = 0 > line = 0x22b5720 "maintenance internal-error " > > p@entry is not particularly useful here because the `line' local variable > contains the same. One can imagine in other real world applications it can be > useful - for a backtrace sent by user where you do not have a reproducer and/or > the core file (the case of ABRT bugreports). > > The parameter@entry lines are not displayed if they are not useful. Therefore > if they would display the same value as the current parameter value or if GDB > cannot successfully determine the entry value. > > It is displayed by `bt full' and `info args'. RFC is whether it is not too > verbose and/or if it should not be displayed some way even with normal `bt'. > Also whether there should be some `set' variable to forget about @entry values. Thanks. I'm not sure the DWIM-ish logic you describe is a good idea. Why not show the values at entry always, not just subject to the conditions you described? What will we lose? And why should GDB second-guess what the user will find "useful"? Also, why display this just for "bt full"? This feature will be very important for analyzing crash tracebacks, and many such reports come without "bt full", just with "bt". See also my question about the @entry qualifier elsewhere in this thread. It's not clear from the docs whether the values at entry will be shown only when they are passed in registers, or always. The text sounds as if it is always. Otherwise, I have no comments for the documentation part. Thanks.