This is the mail archive of the
mailing list for the GDB project.
Re: Frame sniffers in Python/Guile/*
- From: Andy Wingo <wingo at igalia dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>, Alexander Smundak <asmundak at google dot com>, Doug Evans <xdje42 at gmail dot com>
- Date: Mon, 09 Mar 2015 20:18:54 +0100
- Subject: Re: Frame sniffers in Python/Guile/*
- Authentication-results: sourceware.org; auth=none
- References: <87d24r4jgx dot fsf at igalia dot com> <54FDBE7B dot 9070405 at redhat dot com>
Thanks for the detailed comments! Comments inline and a brief summary
at the end.
On Mon 09 Mar 2015 16:38, Pedro Alves <email@example.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:
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-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
> 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.)
* 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
* 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