From patchwork Tue Aug 28 08:43:32 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 29088 Received: (qmail 20489 invoked by alias); 28 Aug 2018 08:43:40 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 20474 invoked by uid 89); 28 Aug 2018 08:43:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.2 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=fp, wondered X-HELO: mail-wr1-f68.google.com Received: from mail-wr1-f68.google.com (HELO mail-wr1-f68.google.com) (209.85.221.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 Aug 2018 08:43:36 +0000 Received: by mail-wr1-f68.google.com with SMTP id o37-v6so746841wrf.6 for ; Tue, 28 Aug 2018 01:43:36 -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:in-reply-to:user-agent; bh=4tXrPI/uj6A3VdlKgpEinMjYlj3guVI6y4yOsRnjYTs=; b=hdwyWpt8ke51YkcAvjIxISIk4tDf6ooLbAOgmUjzXBdwoA/DrrRxaeJTSS8cdNV3iN QLobSe7VH7fYj/tQ/KMRtato1LYb2OPFc/kN/5lfEh/CzxgA1vRclr2hoKt6QM9TiS5Z B/bV56SV4BPAvcp5toM+cv+vpVaoOibXGx3fGpoGfqAZcsDRF3x7niRHw6kD3F/GBLmr nxtq6Dpqzl+l1aYpeQ8PosDhSqWiCjf5BJhuIQIRgjtoP+XgvBW6jd2DrqTT3oCrWcHq GQyyIR5ovUHdpXlTWebRcUafmwPlGHxVYZdBEzm/01KajEye/UVfpYqD92rK/zJsHz5w WFOg== Return-Path: Received: from localhost (host86-134-20-86.range86-134.btcentralplus.com. [86.134.20.86]) by smtp.gmail.com with ESMTPSA id l24-v6sm1001625wrb.65.2018.08.28.01.43.33 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 28 Aug 2018 01:43:33 -0700 (PDT) Date: Tue, 28 Aug 2018 09:43:32 +0100 From: Andrew Burgess To: Eli Zaretskii Cc: gdb-patches@sourceware.org, philippe.waroquiers@skynet.be Subject: Re: [PATCHv5 0/2] gdb: Change how frames are selected for 'frame' and 'info frame'. Message-ID: <20180828084332.GI32506@embecosm.com> References: <20180725181406.GA3155@embecosm.com> <20180827110353.GE32506@embecosm.com> <83zhx74yva.fsf@gnu.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <83zhx74yva.fsf@gnu.org> X-Fortune: The air conditioning water supply pipe ruptured over the machine room X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes * Eli Zaretskii [2018-08-27 18:23:37 +0300]: > > Date: Mon, 27 Aug 2018 12:03:54 +0100 > > From: Andrew Burgess > > Cc: Philippe Waroquiers , > > Eli Zaretskii > > > > Eli: > > > > In this message: > > https://sourceware.org/ml/gdb-patches/2018-07/msg00670.html > > Philippe highlighted that you might have some reservations about > > this patch series, which I think is currently the main blocker for > > this patch getting approval. > > > > In the thread started here: > > https://sourceware.org/ml/gdb-patches/2018-05/msg00299.html > > and ending here: > > https://sourceware.org/ml/gdb-patches/2018-06/msg00142.html > > you did review and approve one of the original patch variants, which > > is most like the "level" variant of the patch submitted here: > > https://sourceware.org/ml/gdb-patches/2018-08/msg00337.html > > > > I would be really grateful if you could let me know your current > > thoughts on this patch, are you happy to have the "level" variant > > merged based on your previous approval, or has you position changed? > > I just said > > I question the wisdom of changing such veteran terminology. > > And then: > > If we are going to make this change, then I would suggest to keep the > index entry, _add_ to it an entry about "frame level", and explain > here what that level is, something like this: > > @value{GDBN} labels each existing stack frame with a @dfn{level}, a > number that is zero for the innermost frame, one for the frame that > called it, and so on upward. These level numbers give you a way of > designating stack frames in @value{GDBN} commands. > > IOW, I urged us to think whether we really want the change (and > invited others to comment). Then I had a small suggestion for if we > do make the change. > > That is all. It was never my intention to block the patch, and if my > words were unfortunate enough to be interpreted that way, I apologize. Thanks for your feedback. I didn't mean you were intentionally blocking the patch, rather, there was some uncertainty, and _that_ was blocking. I understand your concerns about changing existing terminology, and I agree that this is a real issue that should be considered. I like your proposed new paragraph as it mentions both the word 'level' and the word 'number', and I wondered if we couldn't sidestep the issue of which term is "correct", at least for a little while, with something like this: @value{GDBN} labels each existing stack frame with a @dfn{level}, a number that is zero for the innermost frame, one for the frame that called it, and so on upward. These level numbers give you a way of designating stack frames in @value{GDBN} commands. The terms @dfn{frame number} and @dfn{frame level} can be used interchangably to describe this number. I'd also propose we add both 'frame number' and 'frame level' to the concept index (see patch below). Do you think that if I added this chunk to the existing level patch we would have something that was clear enough to merge? Thanks, Andrew diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index a2e405d5dfc..694f2ca5e95 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -7393,12 +7393,14 @@ in a register called the @dfn{frame pointer register} (@pxref{Registers, $fp}) while execution is going on in that frame. +@cindex frame level @cindex frame number -@value{GDBN} assigns numbers to all existing stack frames, starting with -zero for the innermost frame, one for the frame that called it, -and so on upward. These numbers do not really exist in your program; -they are assigned by @value{GDBN} to give you a way of designating stack -frames in @value{GDBN} commands. +@value{GDBN} labels each existing stack frame with a @dfn{level}, a +number that is zero for the innermost frame, one for the frame that +called it, and so on upward. These level numbers give you a way of +designating stack frames in @value{GDBN} commands. The terms +@dfn{frame number} and @dfn{frame level} can be used interchangably to +describe this number. @c The -fomit-frame-pointer below perennially causes hbox overflow @c underflow problems.