Re: Frame sniffers in Python/Guile/*

[Pedro Alves <palves at redhat dot com>]

On 03/09/2015 07:18 PM, Andy Wingo wrote:
> 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.

Can you give an example, so we can understand the requirements better?

The main problem would be unwind-past-this_frame: that is, something doing
get_prev_frame(this_frame), get_frame_id (this_frame) or something like that
while inside the sniffer.  Unwinding registers from the next frame
to build a cache to compute the frame id or figure out where registers
were saved is ok.

> 
>> 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?

I don't think I understand this question.

> (IIUC links between values and frames was part of the issue in that mail.) 

The follow up mail makes it clearer, perhaps:

  https://www.sourceware.org/ml/gdb-patches/2013-11/msg00681.html

If you look at the backtrace there, you'll notice that
while inside dwarf2_frame_sniffer(this_frame) (frame #8), we ended
up in frame_register_unwind(this_frame), and that ends up with
bogus results.

> 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> :(

I'm afraid I don't know what "Maybe<UnwindInfo>" is.

> 
>> 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?

It probably makes sense to refer to those.  As long as e.g.,
can e.g., make get_current_frame() really return the current frame.
But from what I understood, we end up instead falling back to NULL?
If we're going to give the wrong answer, it makes me nervous to have
to support doing it going forward.  :-/

> 
>> 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.)

Speaking of which, it occurred to me that we'll likely have problems
on architectures that hide all raw registers (by making them unnamed)
behind pseudo registers, like MIPS.

> 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.

Thanks,
Pedro Alves