From: Tom Tromey <tom@tromey.com>
To: "Botond Dénes" <bdenes@scylladb.com>
Cc: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [RFC PATCH v1] Support inspecting green threads
Date: Thu, 10 Sep 2020 15:24:40 -0600 [thread overview]
Message-ID: <874ko5gw9z.fsf@tromey.com> (raw)
In-Reply-To: <e1af5e3185c7586c6ce014da8c0da8fed5eec48b.camel@scylladb.com> ("Botond =?utf-8?Q?D=C3=A9nes=22's?= message of "Wed, 19 Aug 2020 15:14:56 +0300")
Botond> Now I started thinking whether we could extend this support to
Botond> stackless fibers.
...
Botond> These stackless fibers are made up of continuation objects, which form
Botond> an intrusive forward linked-list. Each continuation object is a
Botond> callable and a pointer to the next continuation that should be executed
Botond> next, with the value computed by this continuation.
Botond> These fibers are an absolute pain to debug in gdb. Backtracing of
Botond> course just takes you back to the event loop. As the continuations are
Botond> classes templated on lambdas, their type name (even if known based on
Botond> the vptr of the continuation object) is unreadable.
Botond> I'm wondering if we could piece together these continuations into a
Botond> pseudo backtrace, making at least lambda captures (those the optimizer
Botond> forgot to destroy) inspectable. AFAIK gdb already has a notion of
Botond> pseudo frames that it uses to render inline frames into backtraces.
Botond> We should of course allow this mode to be disabled because sometimes
Botond> you do want to look at the event loop frames.
Yeah, this might be somewhat doable today by writing a customer frame
filter and some helper code. The idea would be to capture locations as
the chain of continuations progresses, then replay these locations in
the frame filter.
One problem with this sort of approach is that local variables would be
unavailable for these saved frames, but that's just generally an issue
with continuations I suppose.
Tom
prev parent reply other threads:[~2020-09-10 21:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-14 15:25 Botond Dénes
2020-08-14 15:27 ` Botond Dénes
2020-08-14 15:33 ` H.J. Lu
2020-08-17 21:34 ` Tom Tromey
2020-08-19 12:14 ` Botond Dénes
2020-09-10 21:24 ` Tom Tromey [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874ko5gw9z.fsf@tromey.com \
--to=tom@tromey.com \
--cc=bdenes@scylladb.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox