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

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Tue, 19 Jul 2011 13:41:48 +0200
> From: Jakub Jelinek <jakub@redhat.com>
> Cc: Jan Kratochvil <jan.kratochvil@redhat.com>, drow@false.org,
>         gdb-patches@sourceware.org
> 
> > But then why don't we just show the value at entry in the function
> > call line?  IOW, show this:
> > 
> >   #8  0x000000000048c50d in execute_command (p=0x22b5720 "maintenance internal-error", from_tty=1) at top.c:438
> > 
> > instead of this:
> > 
> >   #8  0x000000000048c50d in execute_command (p=0x22b573b "", from_tty=1) at top.c:438
> > 	p@entry = 0x22b5720 "maintenance internal-error "
> > 
> > Also show those entry-time values in "info args", as you already
> > suggested.
> 
> There are several possibilities of what info may be available for
> a parameter:

Thanks, I understand all that, but I'm not sure I see how is this
relevant to the issue at hand.

> 1) the entry value as well as current value of the parameter are known
>    and known to be equal

This is trivial.

> 2) both entry value and current value of the parameter are known, but are
>    different

This is the case I was talking about.  Normally, "print foo" shows
the current value of `foo'.  The values in the function call currently
show the current values, but I think they should show the entry-time
values with this new feature.

> 3) only entry value is known, current value is optimized out

Show the entry value in the call and backtraces, say "optimized out"
in response to "print foo".

> 4) only current value is known, entry value isn't provided (the value
>    passed to the function in the caller wasn't saved in any call saved
>    register or memory slot and wasn't constant, or the compiler didn't
>    provide call site info for it)

Show "optimized out" in calls and backtraces, the current value in
response to "print foo".

> 5) neither the entry value nor current value are known (both are
>    optimized out)

Show "optimized out" for both; again, trivial.

> It might be a good idea to give the user for backtraces the ability
> to say his preference what kind of values he would like to see and what
> information should be printed in all of the above cases, but in any
> case if anything but the current value is printed in the backtrace, it
> should be obvious what kind of value it is (some way to say that
> it is both the current and entry value, aka case 1), some other way
> to print both values if requested (case 2), if user wants to print
> just one of the values it would be like 3) or 4) ), etc.

I'd rather we showed what we DTRT without asking the user to provide
too much guidance.

> Jan's 01-05 patches are just for using the entry value in computation
> of a current value (either when the compiler knows that somewhere
> both values are the same, i.e. case 1), or when the current value
> is based on an entry value (say entry_value + constant etc.), or
> some variable or parameter's current value is based on entry value
> of any of the parameters.

Understood.  I was talking about the second part.