Re: "previous frame inner to this frame" error when unwinding fibers
Andrey Turkin via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <CAA7-ZorVxkhKgwB0Wu_-gBbwNniPBxZEYN9rFy_Dwro9x2pS5w@mail.gmail.com> |
пн, 11 дек. 2023 г. в 01:30, Tom Tromey <[email protected]>: > > >>>>> "Andrey" == Andrey Turkin via Gdb <[email protected]> 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).