From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30507 invoked by alias); 19 Jul 2011 10:31:19 -0000 Received: (qmail 30483 invoked by uid 22791); 19 Jul 2011 10:31:17 -0000 X-SWARE-Spam-Status: No, hits=-7.0 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 10:31:03 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p6JAUxGn029870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2011 06:30:59 -0400 Received: from host1.jankratochvil.net (ovpn-116-20.ams2.redhat.com [10.36.116.20]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p6JAUuis029938; Tue, 19 Jul 2011 06:30:57 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p6JAUur7021661; Tue, 19 Jul 2011 12:30:56 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p6JAUtiU021656; Tue, 19 Jul 2011 12:30:55 +0200 Date: Tue, 19 Jul 2011 10:55:00 -0000 From: Jan Kratochvil To: Eli Zaretskii Cc: Daniel Jacobowitz , gdb-patches@sourceware.org Subject: Re: [RFC 06/12] entryval: Display @entry parameters in bt full Message-ID: <20110719103055.GA21344@host1.jankratochvil.net> References: <20110718201852.GG30496@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) 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/msg00454.txt.bz2 On Tue, 19 Jul 2011 11:56:45 +0200, Eli Zaretskii wrote: > Maybe I'm missing something important here (in fact, most probably I am), Yes. > but let me turn the table and ask: why do we need that @entry > qualifier at all? The patchset would be useful for recovering the lost values without showing or entering the @entry string anywhere, that is without having the entry values explicitly user accessible at all. > Why not just show the name of the parameter itself > in the backtrace and let users evaluate `p' in expressions to mean > that value which GDB can recover under this series of patches? Yes, it works that way. 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. I think it is separated well enough in the patchset, up to incl. 05/12 it is about values recovery, from 06/12 it is about user-accessible entry values. Thanks, Jan