Re: Frame sniffers in Python/Guile/*

[Andy Wingo <wingo at igalia dot com>]

On Sun 08 Mar 2015 21:03, Doug Evans <xdje42@gmail.com> writes:

> Andy Wingo <wingo@igalia.com> writes:
>> [...]
>>
>> And so on.  From what I can tell, all of this is because there is no
>> selected frame.  I recognize that this situation reflects reality in
>> some way -- we're still building the selected frame -- but is there any
>> way that we could have GDB be in a more "normal" state while the unwind
>> callback is running?
>
> I think one gets into trouble if one tries to
> apply the word "normal" to gdb. :-)

:-)

> I don't have any simple suggestions. Maybe others will.
> A lot of times improving/fixing gdb requires first
> improving/fixing several other parts first.
> Welcome to gdb. :-)

Hehe OK :)

In this case I came up with what can only be considered a hack, but one
which does solve the issue for me.  The root of the issue is described
in another mail, which I quote:

  1. The Guile unwinder's sniffer is called on the innermost frame.
     That sniffer calls out to Guile.

  2. Many actions, for example looking up a symbol without specifying a
     block. will request the selected frame.

  3. get_selected_frame() sees there is no selected frame, and goes to
     get_current_frame() and will select that.

  4. get_current_frame creates a sentinel frame and unwinds that to
     produce the innermost frame.

  5. After unwinding saved registers from the sentinel, frame.c finishes
     constructing the innermost frame by doing a compute_frame_id() on
     the frame.

  6. compute_frame_id() goes to compute the unwinder for the innermost
     frame, in order to call the this_id() method, which leads us back to
     the beginning.

  http://article.gmane.org/gmane.comp.gdb.patches/105431

The same thing could happen in python on the innermost frame.  My
terrible solution is somewhat hidden in this patch:

  http://article.gmane.org/gmane.comp.gdb.patches/105473

The idea is that frame_unwind_find_by_frame detects recursion and
signals an error, at least for the innermost frame.  (Actually, it
should probably error on recursion for any frame; unwinding is
iterative, not recursive.)

Then get_prev_frame uses the frame_unwind_is_unwinding_innermost_frame()
interface to avoid re-unwinding the sentinel frame, and instead returns
NULL.  Terrible, right?  But it does cause get_current_frame to the
sentinel frame, allowing get_selected_frame() to succeed, which is at
least useful to get the current architecture.  Yuck!

What does the nice solution look like here?  The situation is, no
selected frame, we're unwinding the innermost frame, then via
Guile/Python/etc something indirectly calls get_selected_frame() in
order to get some data from the frame, like the architecture.  Do we
change all of these to use get_selected_frame_if_set, then fall back to
get_current_frame_or_sentinel() ?

Andy