From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 8F8F5388A803 for ; Fri, 3 Jul 2020 10:16:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8F8F5388A803 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wr1-x42f.google.com with SMTP id z13so32071881wrw.5 for ; Fri, 03 Jul 2020 03:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=+ErLbwovu5tKsSdgwUS9NDXPZU3vJukjK8b4QaIGkAs=; b=GQ7LmwzTSqOqIDUqawSToG6i5dNH/iLC+UqwPtlxKTAM290nxvFJ8SPCygwhvHBPbs ThOq/kL8e1VaKxOvDeQ0Cf8psVL8twIccQTwchMFNPjEx6qvWMU/HB9xaPxN+L8FrGux J2/QTUIVvS4mmSOLE4hG1MUnWcOVBAqaN2uH4uEdkvDeUOwHdbIa3+2WlfwOmU4PlQpU jJzv/+JUcow1QcY7F4YCAnnTjDKiOS9QKhJLQqc1rLG+Y3Gt3bQwhYVunwaV2zbubw3H 2zdz4WbuYlxfJfoGsKs9G2/svtz1DwrrjrBRd5rRv/kKACFFuGApHWrJZOTJVuSNwGwe DQyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=+ErLbwovu5tKsSdgwUS9NDXPZU3vJukjK8b4QaIGkAs=; b=lmlPaSknNbKG6h8YDhqsC8fiA4Yj33dsfc9m8pXPNyOR6yIIK1KqsyDvcoidk3Q1qW BYcUB9pWk6wV3OOPHr7RbyuTw853NRrO8Bg9vlUSzVSBYQ5H3AP+P3H/69YffbJC4wwj pufKK/hCdye3h77eUZXdZC8YACj6uf0++zVF7g+Gt6rzp8jG9/Q6UF/egUR5mCHIiN05 X4FjPaAKxPDka2aUGtBuyHtxYHcx7TEpEwF+AueRkQfjubl7gYU4c0lYFn+C2HmoIkif aDi7X/NMHWIcK1prFAhTpYPcRAZhqKtrcCMlWqu0PpSn4iegvyLkEYJaRkwcb1/L2NrO e0/A== X-Gm-Message-State: AOAM532eiqc4rvUYtd6KMGKnKKl+ee/BhWv+xFCzqxKcXu7zUMrpgQZl 4jpBOZr3WPQ1vZ2KQbCfibvn4FIJf7Y= X-Google-Smtp-Source: ABdhPJynNMSy2eQEHAHG3vgBaAC3mzyYCFlgsAgBlbTqqXlv7d4U+Hu8efTdWemBs6YySRZmPeH7OA== X-Received: by 2002:a05:6000:128e:: with SMTP id f14mr39220752wrx.276.1593771383581; Fri, 03 Jul 2020 03:16:23 -0700 (PDT) Received: from localhost (host109-148-134-178.range109-148.btcentralplus.com. [109.148.134.178]) by smtp.gmail.com with ESMTPSA id p17sm12644418wma.47.2020.07.03.03.16.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Jul 2020 03:16:23 -0700 (PDT) Date: Fri, 3 Jul 2020 11:16:22 +0100 From: Andrew Burgess To: Botond =?iso-8859-1?Q?D=E9nes?= Cc: gdb@sourceware.org Subject: Re: Stack unwinding for green threads Message-ID: <20200703101622.GF3463@embecosm.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Operating-System: Linux/5.6.15-200.fc31.x86_64 (x86_64) X-Uptime: 11:02:04 up 25 days, 9 min, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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 10:16:26 -0000 * Botond D=E9nes [2020-07-03 12:50:54 +0300]: > Hi, >=20 > 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()`. >=20 > 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. 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#Select= ion [2] https://sourceware.org/gdb/current/onlinedocs/gdb/Unwinding-Frames-in-P= ython.html#Unwinding-Frames-in-Python [3] https://sourceware.org/gdb/current/onlinedocs/gdb/Frame-Filter-API.html= #Frame-Filter-API >=20 > Thanks, > Botond >=20 > [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 >=20