public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Paul Hilfinger <Hilfinger@adacore.com>, gdb-patches@sourceware.org
Subject: Re: [RFA] Have block_innermost_frame start from selected frame
Date: Wed, 28 Dec 2011 15:41:00 -0000	[thread overview]
Message-ID: <20111228153008.GN23376@adacore.com> (raw)
In-Reply-To: <20111228130130.GA1855@host2.jankratochvil.net>

> refrenced doc:
> 	If you wish, you can specify a static variable in a particular
> 	function or file, using the colon-colon (`::') notation:
> 		FILE::VARIABLE
> 		FUNCTION::VARIABLE
> 
> In such case the doc should be updated, particularly that it has became now
> related to the currently selected frame.

Good idea. (and thanks for catching the need to update the
funtion description comment).

> > This change causes block_innermost_frame to start looking from the selected
> > frame, if there is one.
> 
> It may be all even more tricky than it was before.  What about using
> query() if such reference is ambiguous?

What do you mean by ambiguous? Is it the case described here, where
we have multiple frames for the given FUNCTION?

I don't think we should query(). Users often respond negatively
to query, particularly in a case like this where we can make
the behavior unambiguous and easily describable.

I think one reason why I like Paul's choice is the fact that his
suggestion opens the expression to something that is more useful
than the original behavior. With the new behavior, you can get
the old behavior by simply switching back to frame 0, and then
querying FUNCTION::VARIABLE. But the new behavior introduces
the possibility of getting the value of a FUNCTION::VARIABLE inside
another frame by simply selecting that frame. It's the only way
to get the value of "var" in our testcase, and you cannot currently
do it with the old behavior.

> It may not be so easy determining the ambiguity.  Something like
> checking symbol_read_needs_frame() and then also checking if there
> exist >= 2 different frames containing the block.

I think simple is good enough, in this particular case.

-- 
Joel

  reply	other threads:[~2011-12-28 15:30 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-27 19:59 Paul Hilfinger
2011-12-28 13:10 ` Jan Kratochvil
2011-12-28 15:41   ` Joel Brobecker [this message]
2011-12-28 16:00     ` Jan Kratochvil
2011-12-28 17:23       ` Joel Brobecker
2011-12-29 20:30   ` Paul Hilfinger
2011-12-29 23:13     ` Jan Kratochvil
2011-12-28 15:16 ` Jan Kratochvil
2011-12-30 21:54 Paul Hilfinger
2011-12-31  8:58 ` Eli Zaretskii
2011-12-31 21:40   ` Paul Hilfinger
2012-01-09  7:17   ` Paul Hilfinger
2012-01-09 17:14     ` Eli Zaretskii
2012-01-09 19:59       ` Paul Hilfinger
2012-01-10  5:21     ` Joel Brobecker
2012-01-10 10:28       ` Eli Zaretskii
2012-01-10 10:40       ` Joel Brobecker

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=20111228153008.GN23376@adacore.com \
    --to=brobecker@adacore.com \
    --cc=Hilfinger@adacore.com \
    --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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).