From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96187 invoked by alias); 25 Jul 2018 18:14:13 -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 96172 invoked by uid 89); 25 Jul 2018 18:14:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.4 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=versus, recall X-HELO: mail-wm0-f41.google.com Received: from mail-wm0-f41.google.com (HELO mail-wm0-f41.google.com) (74.125.82.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Jul 2018 18:14:10 +0000 Received: by mail-wm0-f41.google.com with SMTP id s9-v6so6982241wmh.3 for ; Wed, 25 Jul 2018 11:14:10 -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 :user-agent; bh=O4411gndExMEinooULS36b2aAoivsd4nQsoCjnCTGuM=; b=NYeges5X2MGV7cmaK2Rl9pC1oOTm8Yuh77Xmpa/JyZUVSgoUQ39DONwH4Wca0j6WxD 9oPJi6dmJqM53At++uy5sXbuqUKhciQehczRmy290Ep2SWhIQzKk8Vl1XjZLABisxGO0 Jp8emBdGb6OMoUZqKOdKl+bfkHd06lkGC6cRc8LX+PDN5bort90Hzewn41HN83pm6FMu IXefNgIN9KOfclGv2653DsX6m7WSky3tBf7pv6gaCaECws9SjHn7O98kcD9EaxioeMWA /fXs7uXKospm1JvMnT7J2NHWRQMTlGQQ4YL0RsvV0TosPwD2FLWWkhh6adpW9xsO3Ty8 pFNQ== Return-Path: Received: from localhost (host86-162-243-217.range86-162.btcentralplus.com. [86.162.243.217]) by smtp.gmail.com with ESMTPSA id n17-v6sm4763360wmc.13.2018.07.25.11.14.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 25 Jul 2018 11:14:07 -0700 (PDT) Date: Wed, 25 Jul 2018 18:14:00 -0000 From: Andrew Burgess To: Philippe Waroquiers Cc: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: [PATCHv4] gdb: Change how frames are selected for 'frame' and 'info frame'. Message-ID: <20180725181406.GA3155@embecosm.com> References: <20180607161915.9425-1-andrew.burgess@embecosm.com> <20180717155751.30898-1-andrew.burgess@embecosm.com> <1532378755.1467.1.camel@skynet.be> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <1532378755.1467.1.camel@skynet.be> X-Fortune: Life is a sexually transmitted disease with 100% mortality. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00698.txt.bz2 * Philippe Waroquiers [2018-07-23 22:45:55 = +0200]: > On Tue, 2018-07-17 at 16:57 +0100, Andrew Burgess wrote: > > Now that the 'frame apply' command has been merged to master, this is > > a rebase of the v3 patch. Merge conflicts have been resolved, but the > > content is largely unchanged. > FWIW, I like the idea of the patch, as it is too easy to > (too silently) get a wrong frame with 'frame = '. >=20 > Find below some comments to discuss the terminology 'frame level' > versus 'frame number'. >=20 > Philippe >=20 > >=20 > > Thanks, > > Andrew > >=20 > > --- > >=20 > > The 'frame' command, and thanks to code reuse the 'info frame' and > > 'select-frame' commands, currently have an overloaded mechanism for > > selecting a frame. > >=20 > > These commands take one or two parameters, if it's one parameter then > > we first try to use the parameter as an integer to select a frame by > > level (or depth in the stack). If that fails then we treat the > > parameter as an address and try to select a stack frame by > > stack-address. If we still have not selected a stack frame, or we > > initially had two parameters, then GDB allows the user to view a stack > > frame that is not part of the current backtrace. Internally, a new > > frame is created with the given stack and pc addresses, and this is > > shown to the user. > >=20 > > The result of this is that a typo by the user, entering the wrong stack > > frame level for example, can result in a brand new frame being viewed > > rather than an error. > >=20 > > The purpose of this commit is to remove this overloading, while still > > offering the same functionality through some new sub-commands. By > > making the default behaviour of 'frame' (and friends) be to select a > > stack frame by level number, it is hoped that enough > > backwards-compatibility is maintained that users will not be overly > > inconvenienced. > >=20 > > The 'frame', 'select-frame', and 'info frame' commands now all take a > > frame specification string as an argument, this string can be any of the > > following: > >=20 > > (1) An integer. This is treated as a frame number. If a frame for > > that number does not exist then the user gets an error. > >=20 > > (2) A string like 'level ', where is a frame number > > as in option (1) above. >=20 > I did a trial to scan the documentation for the usage of 'frame number', > in order to replace it by 'frame level'. > Note that Eli has some reserve about this idea/replacement, > see thread > https://sourceware.org/ml/gdb-patches/2018-07/msg00365.html. I seem to have opened a can of works with the choice of level here. It's been a while since I wrote the original patch (almost 3 years) so, honestly, I can't recall why I picked 'level' over 'number'. It probably seemed more descriptive at the time, but honestly I would be just as happy to use 'number' instead. So, what I'd really like is some guidance from .... well .... anyone who cares really .... level or number ? Thanks, Andrew >=20 > IMO, the sentences (1) and (2) above should preferably > use consistently 'frame level' 'level ' : at the moment, > we seem to semi-randomly use level or number, explaining at some places > that level is a frame number.=20 >=20 > It would be good to clarify exactly what naming convention should > be used, and apply it (more) systematically (in the existing > documentation and/or in this patch). >=20 >=20 >=20 > > (3) A string like 'address
', where
is a > > stack-frame address. If there is no frame for this address then the > > user gets an error. > Below, (5) and (6) are using STACK-ADDRESS instead of ADDRESS. > I am not sure to understand if there is (or not) a difference of concept > between this ADDRESS and the below STACK-ADDRESS. > I am wondering which address we are speaking about. > When doing 'info frame', I get something like: > (gdb) info frame > Stack level 1, frame at 0x7fffffffdf80: > =A0rip =3D 0x555555554f5e in sleeper_or_burner (sleepers.c:86); saved r= ip =3D 0x55555555549d > =A0called by frame at 0x7fffffffe040, caller of frame at 0x7fffffffdf40 > =A0source language c. > =A0Arglist at 0x7fffffffdf70, args: v=3D0x7fffffffdf90 > =A0Locals at 0x7fffffffdf70, Previous frame's sp is 0x7fffffffdf80 > =A0Saved registers: > =A0 rbp at 0x7fffffffdf70, rip at 0x7fffffffdf78 > (gdb)=A0 > Maybe it would be good to reference in the doc the field given > in the above output ? >=20 >=20 > Note that the above command output uses 'Stack level 1', > and not 'Stack number 1' :). >=20 >=20 > >=20 > > (4) A string like 'function ', where is a function name, > > the inner most frame for function is selected. If there is no > > frame for function then the user gets an error. > >=20 > > (5) A string like 'view ', this views a new frame > > with stack address . > >=20 > > (6) A string like 'view ', this views > > a new frame with stack address an the pc . > >=20 > > This change assumes that the most common use of the commands like > > 'frame' is to select a frame by frame level number, it is for this > > reason that this is the behaviour that is kept for backwards > > compatibility. Any of the alternative behaviours, which are assumed to > > be less used, now require a change in user behaviour. > >=20 > > The MI command '-stack-select-frame' has also changed in the same way. > > The default behaviour is to select a frame by level number, but the > > other selection methods are also available. >=20 > In the rest of the patch, assuming there is an agreement about > using frame level instead of frame number, there are some other > occurrences of number to replace/clarify. >=20 > Philippe >=20