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

[Tom Tromey <tromey@redhat.com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> p@entry is not particularly useful here because the `line' local
Jan> variable contains the same.  One can imagine in other real world
Jan> applications it can be useful - for a backtrace sent by user where
Jan> you do not have a reproducer and/or the core file (the case of ABRT
Jan> bugreports).

Jan> The parameter@entry lines are not displayed if they are not useful.
Jan> Therefore if they would display the same value as the current
Jan> parameter value or if GDB cannot successfully determine the entry
Jan> value.

Jan> It is displayed by `bt full' and `info args'.  RFC is whether it is
Jan> not too verbose and/or if it should not be displayed some way even
Jan> with normal `bt'.  Also whether there should be some `set' variable
Jan> to forget about @entry values.

I think it is often confusing to users to see the currently value in a
backtrace.  Certainly this has confused me any number of times.

My first thought is to display this information by default in the
backtrace, even in the short form.

However, then I think there is another possible confusion -- some
arguments may have entry values, and some may not; and I think it would
be nice to clearly distinguish this for users.

How about something like:

#8  0x000000000048c50d in execute_command (p=0x22b573b "" (p@entry=0x22b5720 "maintenance internal-error "), from_tty=1) at top.c:438


Here, the entry value is clearly distinguished and arguments lacking an
entry value are also immediately visible.

If this is too verbose for somebody, let them complain and we can add a
new parameter.

If you think it is important to also distinguish the case where the
argument is equal to its entry value, then we can add additional output
sugar for that, e.g.:

#8  0x000000000048c50d in execute_command (p=p@entry=0x22b573b "whatever", from_tty=1) at top.c:438

Tom