From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32495 invoked by alias); 18 Jul 2011 21:01:59 -0000 Received: (qmail 32486 invoked by uid 22791); 18 Jul 2011 21:01:59 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ew0-f41.google.com (HELO mail-ew0-f41.google.com) (209.85.215.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 18 Jul 2011 21:01:45 +0000 Received: by ewy9 with SMTP id 9so1964136ewy.0 for ; Mon, 18 Jul 2011 14:01:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.98.80 with SMTP id u56mr2369808eef.187.1311022904384; Mon, 18 Jul 2011 14:01:44 -0700 (PDT) Received: by 10.14.127.208 with HTTP; Mon, 18 Jul 2011 14:01:44 -0700 (PDT) In-Reply-To: <20110718201852.GG30496@host1.jankratochvil.net> References: <20110718201852.GG30496@host1.jankratochvil.net> Date: Mon, 18 Jul 2011 22:24:00 -0000 Message-ID: Subject: Re: [RFC 06/12] entryval: Display @entry parameters in bt full From: Daniel Jacobowitz To: Jan Kratochvil Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00446.txt.bz2 On Mon, Jul 18, 2011 at 4:18 PM, Jan Kratochvil wrote: > p@entry is not particularly useful here because the `line' local variable > contains the same. =A0One 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. =A0Th= erefore > 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'. =A0RFC is whether it is not= too > verbose and/or if it should not be displayed some way even with normal `b= t'. > Also whether there should be some `set' variable to forget about @entry v= alues. Thoughts: * It is really frustrating when GDB knows the value of something, but I can't access it as a variable. That means I can't explore it as a typed value without having to copy it, paste it, and add a cast to the right pointer type. There should be a way to get these values back. * Any awesomely useful feature like this one should consider MI access from the start. How would you want to portray this data in an IDE? How would you communicate it through MI to the IDE? I am not in love with the @entry name, but maybe we can combine it with the above... something like "$at_entry(p)" that could be evaluated in an expression? Better naming welcome. --=20 Thanks, Daniel