Re: "previous frame inner to this frame" error when unwinding fibers

[Andrey Turkin via Gdb <gdb@sourceware.org>]

пн, 11 дек. 2023 г. в 01:30, Tom Tromey <tom@tromey.com>:
>
> >>>>> "Andrey" == Andrey Turkin via Gdb <gdb@sourceware.org> writes:
>
> Andrey> I'm trying to write a custom unwinder in Python to unwind through
> Andrey> boost coroutine (so, follow coroutine stack with its caller's stack).
> Andrey> It generally works pretty well except for occasional errors about the
> Andrey> inner frame. Obviously, coroutine switches stack so comparing frame
> Andrey> pointers makes no sense; so, when caller stack happens to be allocated
> Andrey> above coroutine's, the bogus error occurs.
> Andrey> I can see in gdb sources that it knows about gcc's split-stacks and
> Andrey> apparently arch-specific frames, however I found no way for the
> Andrey> unwinder to do anything about it. Is there any way to fix this error
> Andrey> with the current gdb, or do I need to patch the sources?
>
> You'll need to patch gdb.  The current code for handling this sort of
> thing is totally ad hoc and can't be tweaked by the user or from Python.
>
> Letting Python unwinders affect this seems like a nice feature.  Like
> maybe a method on gdb.UnwindInfo that sets a flag, then pipe this
> through to the check in get_prev_frame_always_1.
>
> Maybe some other way is better, I don't know.  I'm definitely open to
> ideas and I think this is worth solving -- I feel it's been asked for
> before.
>
> Tom

One possible solution that comes to my mind is to allow unwinders to
specify the type of the frame (ideally that would be the frame being
unwinded, i.e. one from PendingFrame; UnwindInfo I think is all about
the next frame though). This would be enough to solve this issue since
the inner-frame checking code only works with normal caller-callee
pairs. Not sure which type it would be; sigtrap is the one most
closely resembling it I think but not quite it.

PS: One other thing that is needed for the fiber/coroutine use case is
an ability to perform backtraces from a random starting point.
Backtrace through the switch point is what's needed for active
asymmetric coroutines like generators and such; however it would be
nice to be able to see the current stack of suspended asymmetric
coroutines, or to see the state of symmetric coroutines. This is
something that can be done currently through the abuse of the
backtrace/unwind system, and it sort of works fine, ca. inner frame
thing (see e.g. folly's fiber gdb helper for an example of this). Gdb
can show basic frame information for any frame given sp/ip but I don't
think it is possible to do the unwinding. Would be great if that was
possible to do in some semi-clean manner (to start at any given sp/ip,
or maybe to start from the dummy frame with some registers filled in).