From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Paul Hilfinger <hilfingr@tully.CS.Berkeley.EDU>
Cc: Paul Hilfinger <Hilfinger@adacore.com>, gdb-patches@sourceware.org
Subject: Re: [RFA] Have block_innermost_frame start from selected frame
Date: Thu, 29 Dec 2011 23:13:00 -0000 [thread overview]
Message-ID: <20111229215043.GA25044@host2.jankratochvil.net> (raw)
In-Reply-To: <28663.1325185294@tully.CS.Berkeley.EDU>
On Thu, 29 Dec 2011 20:01:34 +0100, Paul Hilfinger wrote:
> I understand the argument here, but I'm not sure I can agree. The
> ambiguity you speak of already occurs with high frequency, after all,
> since when I say
>
> print x
>
> there may be many local x's lying around,
Yes, some warning/menu-select in such case was one of the ways considered to
implement Tom's ambiguous-linespec patch (which I did not implement myself in
the end at all, sure kudos to Tom).
> that warnings would not be considered helpful.
I really do not mind, not more mails are needed, it is true if
warning/menu/whatever should be printed in this case you are right there are
more such places where it should also happen. Just this is a GDB behavior
change so I thought it may be even more appropriate in such case. Never mind.
> > /* Return the innermost stack frame executing inside of BLOCK, or NULL
> > if there is no such frame. If BLOCK is NULL, just return NULL. */
> >
> > struct frame_info *
> > block_innermost_frame (const struct block *block)
>
> Good point. In fact, do you think we should change the function name?
> The frame is no longer "innermost", after all.
It is still innermost-to-the-selected-frame. There isn't going to be a second
function implementing the original innermost-to-the-current-frame behavior.
I do not see a need for name change in this case.
Thanks,
Jan
next prev parent reply other threads:[~2011-12-29 21:51 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
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 [this message]
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=20111229215043.GA25044@host2.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=Hilfinger@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=hilfingr@tully.CS.Berkeley.EDU \
/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