From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6055 invoked by alias); 19 Jul 2011 11:42:42 -0000 Received: (qmail 6044 invoked by uid 22791); 19 Jul 2011 11:42:42 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sunsite.ms.mff.cuni.cz (HELO sunsite.mff.cuni.cz) (195.113.15.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Jul 2011 11:42:06 +0000 Received: from sunsite.mff.cuni.cz (localhost [127.0.0.1]) by sunsite.mff.cuni.cz (8.14.5/8.14.5) with ESMTP id p6JBfn1o014431; Tue, 19 Jul 2011 13:41:49 +0200 Received: (from jj@localhost) by sunsite.mff.cuni.cz (8.14.5/8.14.5/Submit) id p6JBfmPr014430; Tue, 19 Jul 2011 13:41:48 +0200 Date: Tue, 19 Jul 2011 12:17:00 -0000 From: Jakub Jelinek To: Eli Zaretskii Cc: Jan Kratochvil , drow@false.org, gdb-patches@sourceware.org Subject: Re: [RFC 06/12] entryval: Display @entry parameters in bt full Message-ID: <20110719114148.GA14146@sunsite.ms.mff.cuni.cz> Reply-To: Jakub Jelinek References: <20110718201852.GG30496@host1.jankratochvil.net> <20110719103055.GA21344@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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/msg00459.txt.bz2 On Tue, Jul 19, 2011 at 07:14:04AM -0400, Eli Zaretskii wrote: > > Date: Tue, 19 Jul 2011 12:30:55 +0200 > > From: Jan Kratochvil > > Cc: Daniel Jacobowitz , gdb-patches@sourceware.org > > > > GDB internally knows the value of the parameter at the function entry - to be > > able to recover the values. It has been found out the developers may find it > > useful to be shown the entry values it. It is an additional feature on top of > > the values recovery. > > But then why don't we just show the value at entry in the function > call line? IOW, show this: > > #8 0x000000000048c50d in execute_command (p=0x22b5720 "maintenance internal-error", from_tty=1) at top.c:438 > > instead of this: > > #8 0x000000000048c50d in execute_command (p=0x22b573b "", from_tty=1) at top.c:438 > p@entry = 0x22b5720 "maintenance internal-error " > > Also show those entry-time values in "info args", as you already > suggested. There are several possibilities of what info may be available for a parameter: 1) the entry value as well as current value of the parameter are known and known to be equal 2) both entry value and current value of the parameter are known, but are different 3) only entry value is known, current value is optimized out 4) only current value is known, entry value isn't provided (the value passed to the function in the caller wasn't saved in any call saved register or memory slot and wasn't constant, or the compiler didn't provide call site info for it) 5) neither the entry value nor current value are known (both are optimized out) It might be a good idea to give the user for backtraces the ability to say his preference what kind of values he would like to see and what information should be printed in all of the above cases, but in any case if anything but the current value is printed in the backtrace, it should be obvious what kind of value it is (some way to say that it is both the current and entry value, aka case 1), some other way to print both values if requested (case 2), if user wants to print just one of the values it would be like 3) or 4) ), etc. Jan's 01-05 patches are just for using the entry value in computation of a current value (either when the compiler knows that somewhere both values are the same, i.e. case 1), or when the current value is based on an entry value (say entry_value + constant etc.), or some variable or parameter's current value is based on entry value of any of the parameters. Jakub