This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] Have block_innermost_frame start from selected frame
- From: Paul Hilfinger <hilfingr at tully dot CS dot Berkeley dot EDU>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: Paul Hilfinger <Hilfinger at adacore dot com>, gdb-patches at sourceware dot org
- Date: Thu, 29 Dec 2011 11:01:34 -0800
- Subject: Re: [RFA] Have block_innermost_frame start from selected frame
- References: <20111227195809.672D892BF6@kwai.gnat.com> <20111228130130.GA1855@host2.jankratochvil.net>
> In such case the doc should be updated, particularly that it has became now
> related to the currently selected frame.
> It may be all even more tricky than it was before. What about using query()
> if such reference is ambiguous?
> 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 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
there may be many local x's lying around, both recursive instances of the same
definition or instances of unrelated definitions. Programmers are
expected to understand this and already have a mechanism for specifying
which they mean (up/frame/down). It is a very common situation
(especially for someone like me who is always playing around with
compilers in which a significant percentage of calls are recursive). I
am inclined to think, therefore, that warnings would not be considered helpful.
> And the comment of this function is no longer valid then:
> /* 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.