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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 18 Jul 2011 22:18:53 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> 
> this is a first kind of access to the entry values.  A (non-testcase) demo is:
> 
> #8  0x000000000048c50d in execute_command (p=0x22b573b "", from_tty=1) at top.c:438
> 	p@entry = 0x22b5720 "maintenance internal-error "
> 	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 	arg = <optimized out>
> 	cleanup = 0x28333b0
> 	c = 0x24996d0
> 	flang = <optimized out>
> 	warned = 0
> 	line = 0x22b5720 "maintenance internal-error "
> 
> 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.

Thanks.

I'm not sure the DWIM-ish logic you describe is a good idea.  Why not
show the values at entry always, not just subject to the conditions
you described?  What will we lose?  And why should GDB second-guess
what the user will find "useful"?

Also, why display this just for "bt full"?  This feature will be very
important for analyzing crash tracebacks, and many such reports come
without "bt full", just with "bt".

See also my question about the @entry qualifier elsewhere in this
thread.

It's not clear from the docs whether the values at entry will be shown
only when they are passed in registers, or always.  The text sounds as
if it is always.

Otherwise, I have no comments for the documentation part.

Thanks.