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

пн, 11 дек. 2023 г. в 20:46, Tom Tromey <[email protected]>:
>
> 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/[email protected]/
>
> 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

Stackful coroutines I've ever encountered are very close to
cooperative green threads - minus an underlying scheduler - in their
implementation (separate stack + ucontext to store ABI-saved
registers); a mental model is a bit different. I like the idea you
proposed in that thread, with a caveat that the green threads would be
more ephemeral. E.g. if I want to see the state of a coroutine, I'd
spin up a green thread for it, switch to it and do whatever I'd
usually do with a thread of execution; and then when I'm done I'd
switch over to another thread and wind the green thread down so it is
no more (or maybe I'd cache those threads and destroy them in bulk
upon debuggee resume). As long as there is a Python API to manage them
and as long as their model is similar enough to the OS threads' API,
I'm sure we'd be able to code whatever solution suits one's specific
needs.

Regards, Andrey