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

[Tom Tromey <tom@tromey.com>]

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

SIGTRAMP_FRAME has some special handling in stack.c, so stack traces
would be formatted differently.  I guess we could introduce a new
constant if we wanted to go this route.

Andrey> PS: One other thing that is needed for the fiber/coroutine use case is
Andrey> an ability to perform backtraces from a random starting point.
Andrey> Backtrace through the switch point is what's needed for active
Andrey> asymmetric coroutines like generators and such; however it would be
Andrey> nice to be able to see the current stack of suspended asymmetric
Andrey> coroutines, or to see the state of symmetric coroutines.

A while ago I wrote some initial support for "green threads" by
extending the Python API.  See this thread:

https://inbox.sourceware.org/gdb/YiCk+NNtAGQPhyK5@stefanha-x1.localdomain/

Your situation sounds somewhat similar -- the basic idea is to model
user-space threads, letting Python code replace the sentinel frame.
Then, unlike with 'select-frame', backtraces will work ok.

However maybe your case isn't really identical to this.  Like, do
coroutines store registers?  Maybe some more abstract approach is needed.

Tom