<div dir="ltr">Thank you for that hint, Jim! This infrastructure indeed looks very interesting for my use case.<br>I will most likely use the HistoryThread class to represent the backtrace of the logical coroutine threads.<br><br>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<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 26, 2022 at 6:38 PM Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Aug 26, 2022, at 7:05 AM, Adrian Vogelsgesang via Phabricator via lldb-commits <<a href="mailto:lldb-commits@lists.llvm.org" target="_blank">lldb-commits@lists.llvm.org</a>> wrote:<br>
> <br>
> avogelsgesang added a comment.<br>
> <br>
>> I don't know much about coroutines, but it seems like your goal is to format them like a linked list<br>
> <br>
> actually, my preferred goal would be to show them as a logical, user-level thread. Such that you can type<br>
> <br>
>  thread backtrace cxxcoro:0x55555555b2a0<br>
> <br>
> to get the backtrace of the logical coroutine thread routed at the coroutine at address `0x55555555b2a0`, or maybe even<br>
> <br>
>  thread backtrace cxxcoro:hdl<br>
> <br>
> where `hdl` is evaluated as an expression to identify the coroutine handle from where to dump the backtrace.<br>
> <br>
> Also, it would be neat if those logical threads show up in `thread list`...<br>
> <br>
> But it seems there is currently no infrastructure yet in LLDB for logical threads provided by `LanguageRuntime` plugins.<br>
> <br>
> 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)<br>
<br>
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.<br>
<br>
Jim<br>
<br>
<br>
> <br>
> <br>
> Repository:<br>
>  rG LLVM Github Monorepo<br>
> <br>
> CHANGES SINCE LAST ACTION<br>
>  <a href="https://reviews.llvm.org/D132624/new/" rel="noreferrer" target="_blank">https://reviews.llvm.org/D132624/new/</a><br>
> <br>
> <a href="https://reviews.llvm.org/D132624" rel="noreferrer" target="_blank">https://reviews.llvm.org/D132624</a><br>
> <br>
> _______________________________________________<br>
> lldb-commits mailing list<br>
> <a href="mailto:lldb-commits@lists.llvm.org" target="_blank">lldb-commits@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits</a><br>
<br>
</blockquote></div>