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

Fri Aug 26 18:01:29 PDT 2022

> On Aug 26, 2022, at 5:08 PM, Adrian Vogelsgesang <avogelsgesang at salesforce.com> wrote:
> 
> 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

I don't know how the std::coroutine stuff works...  In what sense is a "pending request" a Thread?  Isn't it a bunch of state and a function pointer that's waiting around to be run?  In which case, maybe we need another entity to describe those?  This is something that we don't handle at all in the "dispatch queue" interface in lldb.  We don't have a way to say "show me all queued but not being serviced" work.  When we get around to supporting that we'd need to add something to describe "queue-able work".

OTOH, if you are really dealing something like a scheduler so that the "pending work" is threads that were moved off of "system threads" and left in memory till they are re-enqueued, then you do need a way to tell lldb about those threads.  There are two ways to do that in lldb.  One is the OperatingSystem Plugin, which requires only that you provide a "Register Context's" for threads that you know about but the system doesn't.  The stack pointer in the context you return should point to the stored stack, and then lldb will do the work of producing the rest of the stack frame for that thread.  The other way is using the ScriptedProcess feature, where you can just make up threads and their stack frames out of whole cloth.  If your thread is still backed by the stack memory it was using, then the OperatingSystem plugin way is the easiest way to go for this.

Jim

> 
> On Fri, Aug 26, 2022 at 6:38 PM Jim Ingham <jingham at apple.com <mailto: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 <mailto: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 <mailto: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/20220826/5a9f3069/attachment.html>