Re: [RFC 06/12] entryval: Display @entry parameters in bt full

[Daniel Jacobowitz <drow@false.org>]

On Mon, Jul 18, 2011 at 4:18 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> 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.

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.

-- 
Thanks,
Daniel