From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gateway36.websitewelcome.com (gateway36.websitewelcome.com [50.116.126.2]) by sourceware.org (Postfix) with ESMTPS id 959FC3858D37 for ; Mon, 17 Aug 2020 21:34:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 959FC3858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=tom@tromey.com Received: from cm10.websitewelcome.com (cm10.websitewelcome.com [100.42.49.4]) by gateway36.websitewelcome.com (Postfix) with ESMTP id 8F18D404B2605 for ; Mon, 17 Aug 2020 15:58:38 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id 7mlckbRpZLFNk7mlckBBEQ; Mon, 17 Aug 2020 16:34:08 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: Date:References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ZuyysDfLAaY1VaG6q2JL3QRDOJvPD8nUZYCbWD485SU=; b=l+iKP5YALznmaTRnJa34W304et CYK6EPZrOW3NPVZpISRzPRVptksof3aJf2kcbb+WDhzREGcSNnzdTNK/nDy0Yck4h792mPhADCHFN rn2l4yZgICmhW5uaoB5bYqITf; Received: from 75-166-101-103.hlrn.qwest.net ([75.166.101.103]:36686 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1k7mlc-002544-Lk; Mon, 17 Aug 2020 15:34:08 -0600 From: Tom Tromey To: Botond =?utf-8?Q?D=C3=A9nes?= Cc: gdb-patches@sourceware.org Subject: Re: [RFC PATCH v1] Support inspecting green threads In-Reply-To: <20200814152557.2128464-1-bdenes@scylladb.com> ("Botond =?utf-8?Q?D=C3=A9nes=22's?= message of "Fri, 14 Aug 2020 18:25:57 +0300") References: <20200814152557.2128464-1-bdenes@scylladb.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) X-Attribution: Tom Date: Mon, 17 Aug 2020 15:34:06 -0600 Message-ID: <87zh6tez3l.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 75.166.101.103 X-Source-L: No X-Exim-ID: 1k7mlc-002544-Lk X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 75-166-101-103.hlrn.qwest.net (bapiya) [75.166.101.103]:36686 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3028.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, JMQ_SPF_NEUTRAL, RCVD_IN_ABUSEAT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NEUTRAL, TXREP autolearn=no 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: Mon, 17 Aug 2020 21:34:11 -0000 >>>>> "Botond" =3D=3D Botond D=C3=A9nes 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], whi= ch Botond> provides green threads in the form of seastar::thread [3]. These th= reads 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 comm= ands 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. Botond> TODO: Botond> * Better interface for the command: instead of a fixed set of regis= ters Botond> (those that happen to be in glibc's jmpbuf on amd64), allow the u= ser 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 appr= oach 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. 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