From: Jakub Jelinek <jakub@redhat.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>,
drow@false.org, gdb-patches@sourceware.org
Subject: Re: [RFC 06/12] entryval: Display @entry parameters in bt full
Date: Tue, 19 Jul 2011 12:17:00 -0000 [thread overview]
Message-ID: <20110719114148.GA14146@sunsite.ms.mff.cuni.cz> (raw)
In-Reply-To: <E1Qj8FY-0007Sq-Hj@fencepost.gnu.org>
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
next prev parent reply other threads:[~2011-07-19 11:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-18 20:21 Jan Kratochvil
2011-07-18 22:24 ` Daniel Jacobowitz
2011-07-19 10:48 ` Eli Zaretskii
2011-07-19 10:55 ` Jan Kratochvil
2011-07-19 11:52 ` Eli Zaretskii
2011-07-19 12:17 ` Jakub Jelinek [this message]
2011-07-19 16:46 ` Eli Zaretskii
2011-07-19 17:22 ` Jakub Jelinek
2011-08-03 17:27 ` Jan Kratochvil
2011-08-03 17:53 ` Jan Kratochvil
2011-08-03 18:13 ` Jan Kratochvil
2011-08-03 18:36 ` Tom Tromey
2011-08-03 19:43 ` Jan Kratochvil
2011-09-02 17:08 ` [MI RFC] entryval: MI access to entry values [Re: [RFC 06/12] entryval: Display @entry parameters in bt full] Jan Kratochvil
2011-09-13 21:35 ` [MI RFC] entryval: MI access to entry values Jan Kratochvil
2011-09-14 8:50 ` Vladimir Prus
2011-09-14 9:13 ` André Pönitz
2011-09-14 9:20 ` Jan Kratochvil
2011-09-14 10:45 ` André Pönitz
2011-10-03 17:00 ` Tom Tromey
2011-10-03 16:57 ` [MI RFC] entryval: MI access to entry values [Re: [RFC 06/12] entryval: Display @entry parameters in bt full] Tom Tromey
2011-10-03 17:05 ` Vladimir Prus
2011-10-03 17:44 ` Jan Kratochvil
2011-10-03 18:14 ` Joel Brobecker
2011-10-10 16:09 ` André Pönitz
2011-07-19 10:57 ` [RFC 06/12] entryval: Display @entry parameters in bt full Eli Zaretskii
2011-07-19 16:21 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110719114148.GA14146@sunsite.ms.mff.cuni.cz \
--to=jakub@redhat.com \
--cc=drow@false.org \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox