From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id 27F983844079 for ; Fri, 3 Jul 2020 17:36:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 27F983844079 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-x632.google.com with SMTP id p20so35030032ejd.13 for ; Fri, 03 Jul 2020 10:36:41 -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=taGiD3MvaWsnUUMRkHc0yfRwOWYbEXSJ02p7/DbiSBA=; b=fOy4c2CmfOE80cQt8us007Ilc1Dbp7KrCsFXY2kKtfYo4G0BfJvNWE02lg/nZZ9C9L WV2+VLLjdXkkJohWqoRDZh9mBIeRYfasXyX4GRqmvNMLIPSy1avIwIHdjCbn9eBz7kzm qDpHkCEXDNGw0TCfiHdC3GhSTdCm6oE6LgEc0vi/g7w8KrbqsVqoo517tTzPPIV2MPf8 W4IUcYNqmixQYAxiGP6OuVowuXyWcdlxFva1AdK3GEUD35bt+Zr/6mmCfGTi3v3kYN5Z lZdQynGUK3zoeT3AfOx4bR/1tUU8fLlqCgkN7mWR1UAfF2nH8VVbxOS+fDXRLxAfZ02r /kuw== 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=taGiD3MvaWsnUUMRkHc0yfRwOWYbEXSJ02p7/DbiSBA=; b=E+JmL+1F+9flC6y5ZwJPMa5oA0yQuFoh4/QqDFMLtXosuQFShGISExxlV6xY8ssIq9 aGdrLwwOS0+3oUBF+AxT7p9vq/4Fw0XzLGSSf5saj1ZXUZHD8YhMQqYTAQIjBFeBY0AC x6MV6OJNmutyKY8WhCzXCtXfayAXfpe972+9JR16NSoLpflJe0/GU9v4d51J8OrLdO1z TT0DFXSQQ5etBI+2AtMhkJiaW6BXHbjf/S1lZWuywMYLwbo30pXR1D10CDAPsD6RC+La DDXImCXpdBfAbz9rFr9MUcfqXNqhLhohwd9yYSaSECZEi0EKW0zCZ6nzvBUDnW7xo9RG BkXA== X-Gm-Message-State: AOAM5332LbafQZITnkjGLSVp8GTYIXYnve1lvZvnf/BwJ3UzkSJXf67w Zu+fOxWxhFUZX+4KIW6lvaqxTuCveDc= X-Google-Smtp-Source: ABdhPJyYHEHELlOJZlfQPXQrODt6N+TrBpwz4dTBHms391FrHJwbQXCr9UzEVens81sVYMZQxrW3Ow== X-Received: by 2002:a17:906:5502:: with SMTP id r2mr31191978ejp.316.1593797799676; Fri, 03 Jul 2020 10:36:39 -0700 (PDT) Received: from localhost.localdomain ([2a02:2f01:8315:eb00:1d10:a7c5:63e1:277a]) by smtp.gmail.com with ESMTPSA id a5sm9323350eda.35.2020.07.03.10.36.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Jul 2020 10:36:39 -0700 (PDT) Message-ID: <547ef9bbba0fdde49a00dcac4df0ece3988d912a.camel@scylladb.com> Subject: Re: Stack unwinding for green threads From: Botond =?ISO-8859-1?Q?D=E9nes?= To: Andrew Burgess Cc: gdb@sourceware.org Date: Fri, 03 Jul 2020 20:36:38 +0300 In-Reply-To: <20200703101622.GF3463@embecosm.com> References: <20200703101622.GF3463@embecosm.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.3 (3.36.3-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 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@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 17:36:42 -0000 On Fri, 2020-07-03 at 11:16 +0100, Andrew Burgess wrote: > * Botond Dénes [2020-07-03 12:50:54 +0300]: > > > Hi, > > > > I'm working on Scylla [1], an application which is built using the > > seastar framework [2]. This framework provides green threads [3] > > that > > have their own stacks. These threads are created with > > `setcontext()` > > and later we switch in/out using `setjmp()`/`longjmp()`. > > > > We have a collection of python scripts [4] to help debug Scylla, > > among > > these we have a utility command which allows switching in/out of > > these > > green threads in gdb. This command basically (tries) to emulate > > `setjmp()`/`longjmp()` in python, saving and restoring registers. > > There > > are several problems with this method. For starters it crashes gdb > > for > > some time now, and also it doesn't work in coredumps, where gdb > > refuses > > to write to registers (even after `set write on`). So for these > > reasons > > I started to look for alternative ways to unwind the stacks of our > > green threads. However after going through the gdb documentation > > [5], > > reading all I could find about threads, stacks, frames and the > > Python > > API I haven't found an entry point to call which would unwind a > > stack > > located at a custom address (not the current $rsp). Is there such > > an > > API that I haven't found? Is there another way to achive what I > > want? > > Alternatively, how hard would it be to implement such an API? > > No, there's currently nothing in GDB for having a look at a different > stack. > > There is 'frame view ...' [1] which I'm sure someone might mention, > as > it almost, sort-of, kind-of feels like this should solve your > problem, > but it wont. > > I did do some work on this area, years ago now, and at the time my > plan was to add a set of commands that solved exactly this problem, > my > intention was to have some kind of 'stack create' command that would > allow you to supply an entire register set (if you wanted) and then > GDB would unwind assuming that this was the "current" register > values. Of course, the only "required" registers would be $sp, and > probably $pc too, but you would have been able to provide others if > you wanted. Anyway I digress, my need for this work disappeared and > this kind of fell of my radar, though I would like to find time to > revisit this ... one day. > > However, thinking about the above kind of gave me an idea, it's not > perfect, but it might work. How about writing a custom Python > Unwinder[2]? > > Here's how I think this might help you: > > (1) By default the custom unwinder is "off", it doesn't claim any > frames, your stack unwinds in the "normal" way. > > (2) Add a command 'magic-stack-unwind ', > this turns "on" (sets a flag) the unwinder, and stores the address > of the register set you want to unwind with. > > (3) The unwinder, now "on" would always claim frames at depth 0, > and > would return all of the registers from your stored register set. > > I think that this would present you with your alternative stack, but > offset by 1 frame, so I think you'd still get the original "current" > frame, but everything below that would be from your alternative > register stack. Not ideal maybe, but it might work. I tried this, but gdb doesn't seem to like the fact that I start returing heap addresses (where customs stacks are located) as $rsp, I get: Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > It might even be possible to make use of frame filters[3] to hide > frame 0, though again, I've never tried hiding frame 0, only even > frames > 0, so I don't know how that would work for you. > > Good luck, > Andrew > > > > [1] > https://sourceware.org/gdb/current/onlinedocs/gdb/Selection.html#Selection > [2] > https://sourceware.org/gdb/current/onlinedocs/gdb/Unwinding-Frames-in-Python.html#Unwinding-Frames-in-Python > [3] > https://sourceware.org/gdb/current/onlinedocs/gdb/Frame-Filter-API.html#Frame-Filter-API > > Thanks, > > Botond > > > > [1] https://github.com/scylladb/scylla > > [2] https://github.com/scylladb/seastar > > [3] http://docs.seastar.io/master/group__thread-module.html > > [4] https://github.com/scylladb/scylla/blob/master/scylla-gdb.py > > [5] https://sourceware.org/gdb/onlinedocs/gdb/index.html > >