This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tue, Jul 19, 2011 at 07:14:04AM -0400, Eli Zaretskii wrote:
> > Date: Tue, 19 Jul 2011 12:30:55 +0200
> > From: Jan Kratochvil <jan.kratochvil@redhat.com>
> > Cc: Daniel Jacobowitz <drow@false.org>, gdb-patches@sourceware.org
> > 
> > GDB internally knows the value of the parameter at the function entry - to be
> > able to recover the values.  It has been found out the developers may find it
> > useful to be shown the entry values it.  It is an additional feature on top of
> > the values recovery.
> 
> 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:
1) the entry value as well as current value of the parameter are known
   and known to be equal
2) both entry value and current value of the parameter are known, but are
   different
3) only entry value is known, current value is optimized out
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)
5) neither the entry value nor current value are known (both are
   optimized out)

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.

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.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]