From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Daniel Jacobowitz <drow@false.org>, gdb-patches@sourceware.org
Subject: Re: [RFC 06/12] entryval: Display @entry parameters in bt full
Date: Tue, 19 Jul 2011 10:55:00 -0000 [thread overview]
Message-ID: <20110719103055.GA21344@host1.jankratochvil.net> (raw)
In-Reply-To: <E1Qj72j-0002Fw-J4@fencepost.gnu.org>
On Tue, 19 Jul 2011 11:56:45 +0200, Eli Zaretskii wrote:
> Maybe I'm missing something important here (in fact, most probably I am),
Yes.
> but let me turn the table and ask: why do we need that @entry
> qualifier at all?
The patchset would be useful for recovering the lost values without showing or
entering the @entry string anywhere, that is without having the entry values
explicitly user accessible at all.
> Why not just show the name of the parameter itself
> in the backtrace and let users evaluate `p' in expressions to mean
> that value which GDB can recover under this series of patches?
Yes, it works that way.
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.
I think it is separated well enough in the patchset, up to incl. 05/12 it is
about values recovery, from 06/12 it is about user-accessible entry values.
Thanks,
Jan
next prev parent reply other threads:[~2011-07-19 10:31 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 [this message]
2011-07-19 11:52 ` Eli Zaretskii
2011-07-19 12:17 ` Jakub Jelinek
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=20110719103055.GA21344@host1.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=drow@false.org \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
/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