Re: Expose Frame Type and Stop Reason in python Unwinder API

[John Baldwin via Gdb <gdb@sourceware.org>]

On 8/21/24 22:28, Andrew Wock via Gdb wrote:
> Hello,
> 
> Recently I wrote a kernel trapframe unwinder using the python API, and
> I was able to successfully extract the registers from the trapframe.
> However, sometimes gdb would throw the "previous frame inner to this
> frame" error on me.  This is because unwinding a trapframe sometimes
> results in unwinding to a different stack.
> 
> The way this is fixed in the internal unwinder API is that there are
> special frame types such as SIGTRAMP_FRAME which don't get checked for
> that error.
> 
> Additionally, some trapframes unwind into userspace.  In those cases
> I'd like to be able to stop the backtrace by setting a stop reason.
> More broadly this would be useful for any case where a user wants to
> stop the stacktrace at a certain point for whatever their use case is.
> 
> I'm interested in moving forward and writing a patch for this.
> 
> One implementation detail I noticed that complicates this
> implementation is that all python unwinders are internally modeled as
> a single C unwinder in py-unwind.c:974.  I believe that in order to
> support a frame type feature, each unwinder will need to be modeled as
> an independent C unwinder.

Yes, I think that's true, or you'd need to have one unwinder per frame
type that you tie all the related unwinders to?

> I am proposing this here to get community feedback on whether this
> feature should be supported.

The other check I've run into is when you have a NULL function pointer
that raises a fault.  There is a check that aborts unwinding unless the
frame type is SIGTRAMP_FRAME IIRC.  I use custom unwinders in C++ for
FreeBSD's kgdb so that they can use SIGTRAMP_FRAME to get around that
limitation.

-- 
John Baldwin