From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com [IPv6:2a00:1450:4864:20::641]) by sourceware.org (Postfix) with ESMTPS id AFA303857C7C for ; Wed, 19 Aug 2020 12:14:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AFA303857C7C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=scylladb.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=bdenes@scylladb.com Received: by mail-ej1-x641.google.com with SMTP id bo3so25974853ejb.11 for ; Wed, 19 Aug 2020 05:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scylladb-com.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=nfyZH28+FLzuqbq4vzrqaaR+t+YnZcnjn7wSGs5sMbU=; b=jfk32ugFEsaYrUC4t21j4C6TMiheoIuBJwkuR3xrUyyrpSgJ2egJGS77NzeJeWaK4R tFpOX916BuQ6Mfftidog/HKjjF08SBFuv9Xrzm6CqmEZJpRz94fx0pr/WSuqp+XMJMyp gML5aHtz6cFnB49JdxcjghYe1W6brYF+q6bjBVFWoSQ3cDR5hjJSDt409Xp4g25oCk6j vX3b61WjtBeSU409pDox5nLtd87Veidmz2asZJx0Q2PzAMM9UePsoQHk4MvsXIfLJHvh oSUBh+uxwO1GfpXepFWc5iRBVAXtk/soM67lCJsMx/CibKjIFlemZR3P1gTaukMRNkJP 572A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=nfyZH28+FLzuqbq4vzrqaaR+t+YnZcnjn7wSGs5sMbU=; b=mut7/qMtbAPC7j6NOSaRvdL87KrswZFhqHHw0hlIOaqLONS78gkP5a2RZ1Zov9k3Cu +vEz51tapk+gU4kq/VSptlvCEW9/1H7lRcGnalQeqJ8D6fdlIcQxf6GcfqMS+hMgtkhW DB8ikt/8ROYkR6AvaMtkl+1I1uazQ62Q2vGIFuYtr3GITYq/RFPeSG1jbR6TqtYsgbMR vyjXcTU8XBG7v6GLMbxktqwvhgPrIzn+mK8H/4h6+37RWGrrUzrgpQe2lYPDwQtvBc1N AULRR2PcF8uFvG+5aoWbLe2olVGC36HxTUIlzbYD4xX+QNjxAcAQ8j1OeH8w45+3SrFs Gy6Q== X-Gm-Message-State: AOAM530I0KR8InLV41Oph5mGOTfavimULtaFu7hGO8ONoyltDbOlZT67 ot6GIZTcqXurHIc/6H79aJODdt8GSbvIIA== X-Google-Smtp-Source: ABdhPJxfLg9f0k4r0LqRhYoVz9tEZpgCHc0jdlYR8Ic264DEpc1RkcaIU0L15Bj2Ma1iX1tkkGglLA== X-Received: by 2002:a17:906:f847:: with SMTP id ks7mr26398766ejb.402.1597839297760; Wed, 19 Aug 2020 05:14:57 -0700 (PDT) Received: from localhost.localdomain ([2a02:2f01:8205:e100:aa9e:e920:cb1e:35d9]) by smtp.gmail.com with ESMTPSA id f21sm17595996edv.66.2020.08.19.05.14.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Aug 2020 05:14:56 -0700 (PDT) Message-ID: Subject: Re: [RFC PATCH v1] Support inspecting green threads From: Botond =?ISO-8859-1?Q?D=E9nes?= To: Tom Tromey Cc: gdb-patches@sourceware.org Date: Wed, 19 Aug 2020 15:14:56 +0300 In-Reply-To: <87zh6tez3l.fsf@tromey.com> References: <20200814152557.2128464-1-bdenes@scylladb.com> <87zh6tez3l.fsf@tromey.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.4 (3.36.4-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 12:15:00 -0000 On Mon, 2020-08-17 at 15:34 -0600, Tom Tromey wrote: > > > > > > "Botond" == Botond Dénes writes: > > Botond> Some applications use green threads that have their own > stacks. One such > Botond> example is Scylla [1] which is using the seastar framework > [2], which > Botond> provides green threads in the form of seastar::thread [3]. > These threads > Botond> are created with `setcontext()` and later we switch in/out > using > Botond> `setjmp()`/`longjmp()` > > Thanks for bringing this up. We've talked about adding a facility > like > this a couple of times -- maybe it's finally time. > > Botond> This patch aims to solve this problem by providing a family > of commands > Botond> which allow inspecting green threads. > Botond> * fiber view - allows inspecting a green thread. This command > takes a > Botond> list of registers as its arguments. More on these later. > Botond> * fiber reset - reset the viewed fiber to the stack proper. > > I like the name. Glad to hear it. :) > > Botond> TODO: > Botond> * Better interface for the command: instead of a fixed set of > registers > Botond> (those that happen to be in glibc's jmpbuf on amd64), allow > the user > Botond> to pass any amount of named registers to override. > Botond> * More documentation. > Botond> * More testing. > Botond> * Code style. > > Botond> I apologize for the mixed code style, but I wanted to probe > my approach > Botond> first, before spending more time on polishing. > > Yeah, don't worry about that yet. > > It may interest you to know that there's already an implementation of > something like this in gdb -- the ravenscar thread code. Ravenscar > is > an Ada runtime that implements green threads. (It is a bit weird > though > in that these threads never exit.) > > gdb handles this by making "fake" threads corresponding to each green > thread. If you "next" or the like, it uses the underlying real > thread > when communicating with the remote. > > One thought I had was that maybe we could generalize this code. In > conjunction with a Python API, we could make it so that 3rd parties > (the > green thread library) could provide the knowledge needed to hook gdb > to > the threads. > > A consequence of taking this approach would be that fibers could be > integrated with threads, with the upside being that fibers would > automatically start working in gdb GUIs. (But maybe there are > downsides > as well -- for instance if a program uses setcontext in a > non-thread-like way. This is worth discussing.) > > I think we'd have to add some kind of "fiber" flag to threads and > then > have a check on operations like "step" to make sure that an attempt > to > step a paused thread is rejected. I don't know for sure but maybe > we'd > need some kind of tweak to ptid as well. This would indeed make these green threads first class citizens in gdb. Now I started thinking whether we could extend this support to stackless fibers. In seastar there are two kinds of fibers: stackful (we call these `seastar::thread` -- these are the green threads) and stackless. The latter is future-promise based and we have experimental glue code to enable C++20 coroutines based on this. These stackless fibers are made up of continuation objects, which form an intrusive forward linked-list. Each continuation object is a callable and a pointer to the next continuation that should be executed next, with the value computed by this continuation. These fibers are an absolute pain to debug in gdb. Backtracing of course just takes you back to the event loop. As the continuations are classes templated on lambdas, their type name (even if known based on the vptr of the continuation object) is unreadable. I'm wondering if we could piece together these continuations into a pseudo backtrace, making at least lambda captures (those the optimizer forgot to destroy) inspectable. AFAIK gdb already has a notion of pseudo frames that it uses to render inline frames into backtraces. We should of course allow this mode to be disabled because sometimes you do want to look at the event loop frames. > Finally, we'd need something > like the "random thread switch" patch that I've been wanting to get > in > for Ravenscar :-) > > A typical way for this to work would be to have some Python code that > sets hidden breakpoints in the thread-start and thread-exit code in a > green thread library. Then, when a thread is started, register it > with > gdb core as one of these "fiber" threads. The Python code would also > be > responsible for supplying registers on request. > > One other thing I'm not sure of in this approach is how non-stop > would > work. I suppose the Python code would need to help with this as > well; > but that seems odd because it implies maybe adding otherwise > undesirable > facilities to green threads libraries. So, perhaps we'd need to > change > how this works in gdb instead. (I think this isn't an issue for > Ravenscar at present because, IIUC, Ravenscar statically assigns > threads > to CPUs; but also because presumably nobody has ever tried the > combination.) > > Tom