Expose Frame Type and Stop Reason in python Unwinder API

Expose Frame Type and Stop Reason in python Unwinder API

[Andrew Wock via Gdb]

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.

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

Thanks,
Andrew Wock

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

[Paul Koning via Gdb]

> On Aug 21, 2024, at 10:28 PM, Andrew Wock via Gdb <gdb@sourceware.org> 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.

For that case, stopping should be an option.  In the past I have found it very useful to be able to continue from kernel to user, in certain situations.

	paul

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

[John Baldwin via Gdb]

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