From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129032 invoked by alias); 13 Jul 2018 06:52:36 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 128526 invoked by uid 89); 13 Jul 2018 06:52:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,SPF_PASS autolearn=ham version=3.3.2 spammy=wisdom, H*r:TLS1.2 X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 13 Jul 2018 06:52:34 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fdrwM-0006TA-1H for gdb-patches@sourceware.org; Fri, 13 Jul 2018 02:52:33 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57989) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fdrwL-0006Sq-TN; Fri, 13 Jul 2018 02:52:29 -0400 Received: from [176.228.60.248] (port=4097 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fdrwL-0000T2-2u; Fri, 13 Jul 2018 02:52:29 -0400 Date: Fri, 13 Jul 2018 06:52:00 -0000 Message-Id: <83fu0neifl.fsf@gnu.org> From: Eli Zaretskii To: Philippe Waroquiers CC: gdb-patches@sourceware.org In-reply-to: <20180712221536.26845-1-philippe.waroquiers@skynet.be> (message from Philippe Waroquiers on Fri, 13 Jul 2018 00:15:36 +0200) Subject: Re: [RFA] (try to) consistently use 'frame level' concept instead of 'frame number'. References: <20180712221536.26845-1-philippe.waroquiers@skynet.be> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00376.txt.bz2 > From: Philippe Waroquiers > Cc: Philippe Waroquiers > Date: Fri, 13 Jul 2018 00:15:36 +0200 > > Following the discussion in the 'frame apply' patch and the patch proposed > in https://sourceware.org/ml/gdb-patches/2018-06/msg00170.html > the idea is rather to speak about 'frame level' to identify a frame, > rather than 'frame number'. I question the wisdom of changing such veteran terminology. > -@cindex frame number > -@value{GDBN} assigns numbers to all existing stack frames, starting with > +@cindex frame level > +In @value{GDBN}, each existing stack frame has a level, 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 > +and so on upward. These levels give you a way of designating stack > frames in @value{GDBN} commands. 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. > -it had a separate frame, which is numbered zero as usual, allowing > +it had a separate frame, which has a level zero as usual, allowing ^^^^^^^^^^ "level of zero". > -Select frame number @var{n}. Recall that frame zero is the innermost > +Select frame level @var{n}. Recall that frame zero is the innermost ^^^^^^^^^^^^^^^^^^^^^^^^^^ "Select frame whose level is @var{n}." Thanks.