Re: Frame sniffers in Python/Guile/*

[Andy Wingo <wingo@igalia.com>]

Hi Pedro,

Thanks for the detailed comments!  Comments inline and a brief summary
at the end.

On Mon 09 Mar 2015 16:38, Pedro Alves <palves@redhat.com> writes:

> On 03/02/2015 01:28 PM, Andy Wingo wrote:
>
>> Unfortunately, the unwind callback is really squirrely -- you can't do
>> much there.
>
> You mean the "unwind->sniffer" callback, right?  If so, that's (so far) by
> design.  The sniffer callback is only supposed to identify whether
> the unwinder can unwind, not do any unwinding at all.  :-/

Unfortunately you have to do some unwinding in order to compute a frame
ID, and the "unwind->this_id" callback runs in approximately the same
environment as the sniffer.

> See here for example:
>
>   https://www.sourceware.org/ml/gdb-patches/2013-11/msg00602.html

Is it important to use frame_unwind_got_memory et al for results?  (IIUC
links between values and frames was part of the issue in that mail.)  In
my unwinders I am just returning values using e.g.

  (value-dereference
   (value-cast (ephemeral-frame-read-register ef "rbp") void**-type))

or something similar.  If this is important, we will need to provide an
interface that looks much more like the unwind interface instead of a
simple Maybe<UnwindInfo> :(

> But imagine the case of:
>
>   #0 frame0  <<<< current
>   #1 frame1  <<<< selected
>   #2 frame2
>
> So what context does make sense for symbol look ups at that point?

Oh, agreed very much.  I was looking up global symbols, like global
constants, and in that case the block is NULL.  But, I was having issues
that I didn't understand using lookup_global_symbol, and lookup_symbol
worked otherwise outside of the sniffer...

Is the issue in the Guile bindings, that they should assume that it's
sensible to get the current architecture, or the selected or current
frame?

> Isn't the correct answer that the sniffer should pass in an explicit
> block to lookup-symbol?

Yes, or in this case lookup-global-symbol.

>>   * You can't value-call, which is not unexpected in general, but the
>>     reason is unexpected: because call_function_by_hand calls
>>     get_current_arch and that doesn't work
>
> Where is that?  I think you meant that the guile wrapper calls
> get_current_arch, not call_function_by_hand.

Yes, I see that now.  I think I was confused.

> Why would the unwinder want to access user / pseudo registers?
> Shouldn't it be working only with raw registers?

Because the user is ignorant? :)  I was pleased that $pc, $sp, and $fp
"worked" otherwise, so I hoped to avoid encoding architecture-specific
things.  Alas.  (Incidentally, my patch still has the problem that
passing in a pseudo register will barf.)

In summary:

  * Is is possible to make a Maybe<UnwindInfo>-style interface to
    sniffers, or should extension languages expose the callbacks
    instead because they really need to be called within their specific
    dynamic environments?

  * Regarding recursion and selected frames -- what do you think about
    the hack in v2 of this patch, which adds
    frame_unwinder_is_unwinding() ?  It is a hack but it has somewhat
    reasonable semantics.

Andy