[Lldb-commits] [PATCH] D132624: [LLDB] Devirtualize coroutine promise types for `std::coroutine_handle`

[Adrian Vogelsgesang via lldb-commits]

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 <jingham at apple.com> wrote:

>
>
> > On Aug 26, 2022, at 7:05 AM, Adrian Vogelsgesang via Phabricator via
> lldb-commits <lldb-commits at 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 at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20220827/6e8a95de/attachment-0001.html>