Thank you for that hint, Jim! This infrastructure indeed looks very interesting for my use case. I will most likely use the HistoryThread class to represent the backtrace of the logical coroutine threads.
Is my understanding correct, that `GetExtendedBacktraceThreads` only allows me to append additional stack trace frames to existing, physical threads, though? I want to expose completely new threads instead. In a sense, I want to display each pending request inside my asynchronous multiplexer as its own thread, such that I can see not only the requests which an OS-level thread is currently working on, but also the onse which are currently queued/not yet processed/blocked on IO On Fri, Aug 26, 2022 at 6:38 PM Jim Ingham <jing...@apple.com> wrote: > > > > On Aug 26, 2022, at 7:05 AM, Adrian Vogelsgesang via Phabricator via > lldb-commits <lldb-commits@lists.llvm.org> wrote: > > > > avogelsgesang added a comment. > > > >> I don't know much about coroutines, but it seems like your goal is to > format them like a linked list > > > > actually, my preferred goal would be to show them as a logical, > user-level thread. Such that you can type > > > > thread backtrace cxxcoro:0x55555555b2a0 > > > > to get the backtrace of the logical coroutine thread routed at the > coroutine at address `0x55555555b2a0`, or maybe even > > > > thread backtrace cxxcoro:hdl > > > > where `hdl` is evaluated as an expression to identify the coroutine > handle from where to dump the backtrace. > > > > Also, it would be neat if those logical threads show up in `thread > list`... > > > > But it seems there is currently no infrastructure yet in LLDB for > logical threads provided by `LanguageRuntime` plugins. > > > > I guess at some point, I will write an RFC about that on discourse. But > before that, I will first do some more exploration on how LLDB works and I > will first grab the low-hanging fruits (like a data formatter for > `std::coroutine_handle` and patching LLVM to emit the necessary debug info) > > lldb has the notion of "extended backtrace threads" - backed by lldb's > "History" threads - that it uses in a similar circumstance handling Darwin > dispatch queues. If you have a thread that is serving a Darwin "dispatch > queue" SBThread.GetExtendedBacktraceThreads will return the backtrace of > the thread that enqueued the work, at the point where the enqueuing is > done. I bet you could make the same setup work for these coroutines. > > Jim > > > > > > > > Repository: > > rG LLVM Github Monorepo > > > > CHANGES SINCE LAST ACTION > > https://reviews.llvm.org/D132624/new/ > > > > https://reviews.llvm.org/D132624 > > > > _______________________________________________ > > lldb-commits mailing list > > lldb-commits@lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
