From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1567 invoked by alias); 19 Jul 2011 16:39:03 -0000 Received: (qmail 1438 invoked by uid 22791); 19 Jul 2011 16:39:01 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout21.012.net.il (HELO mtaout21.012.net.il) (80.179.55.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Jul 2011 16:38:42 +0000 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LOL00H009X56200@a-mtaout21.012.net.il> for gdb-patches@sourceware.org; Tue, 19 Jul 2011 19:38:40 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.229.133.66]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LOL00BNDA8F6UD0@a-mtaout21.012.net.il>; Tue, 19 Jul 2011 19:38:40 +0300 (IDT) Date: Tue, 19 Jul 2011 16:46:00 -0000 From: Eli Zaretskii Subject: Re: [RFC 06/12] entryval: Display @entry parameters in bt full In-reply-to: <20110719114148.GA14146@sunsite.ms.mff.cuni.cz> To: Jakub Jelinek Cc: jan.kratochvil@redhat.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83d3h66x9q.fsf@gnu.org> References: <20110718201852.GG30496@host1.jankratochvil.net> <20110719103055.GA21344@host1.jankratochvil.net> <20110719114148.GA14146@sunsite.ms.mff.cuni.cz> 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/msg00477.txt.bz2 > Date: Tue, 19 Jul 2011 13:41:48 +0200 > From: Jakub Jelinek > Cc: Jan Kratochvil , drow@false.org, > gdb-patches@sourceware.org > > > 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: Thanks, I understand all that, but I'm not sure I see how is this relevant to the issue at hand. > 1) the entry value as well as current value of the parameter are known > and known to be equal This is trivial. > 2) both entry value and current value of the parameter are known, but are > different This is the case I was talking about. Normally, "print foo" shows the current value of `foo'. The values in the function call currently show the current values, but I think they should show the entry-time values with this new feature. > 3) only entry value is known, current value is optimized out Show the entry value in the call and backtraces, say "optimized out" in response to "print foo". > 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) Show "optimized out" in calls and backtraces, the current value in response to "print foo". > 5) neither the entry value nor current value are known (both are > optimized out) Show "optimized out" for both; again, trivial. > 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. I'd rather we showed what we DTRT without asking the user to provide too much guidance. > 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. Understood. I was talking about the second part.