From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20084 invoked by alias); 11 May 2018 14:47:10 -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 19171 invoked by uid 89); 11 May 2018 14:47:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.2 spammy=damaged, sentence, brand 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, 11 May 2018 14:47:08 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fH8Nl-0007h3-0K for gdb-patches@sourceware.org; Fri, 11 May 2018 09:46:52 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36728) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fH8Nk-0007gz-Sd; Fri, 11 May 2018 09:46:48 -0400 Received: from [176.228.60.248] (port=3630 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fH8Ng-0006Fi-PK; Fri, 11 May 2018 09:46:48 -0400 Date: Fri, 11 May 2018 15:44:00 -0000 Message-Id: <83k1sanw3t.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess CC: gdb-patches@sourceware.org In-reply-to: <63020671a997f926cd747677cd4e614e51e81f8d.1525797846.git.andrew.burgess@embecosm.com> (message from Andrew Burgess on Tue, 8 May 2018 17:58:45 +0100) Subject: Re: [PATCHv2 2/2] gdb: Change how frames are selected for 'frame' and 'info frame'. Reply-to: Eli Zaretskii References: <63020671a997f926cd747677cd4e614e51e81f8d.1525797846.git.andrew.burgess@embecosm.com> 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-05/txt/msg00301.txt.bz2 > From: Andrew Burgess > Cc: Andrew Burgess > Date: Tue, 8 May 2018 17:58:45 +0100 > > The 'frame' command, and thanks to code reuse the 'info frame' and > 'select-frame' commands, currently have an overloaded mechanism for > selecting a frame. > > 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 we create a new stack frame and > select that. > > 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 created > rather than an error. > > The purpose of this commit is to remove this overloading, while still > offering the same functionality through some new sub-commands. An alternative could be to request confirmation before creating a new frame. > diff --git a/gdb/NEWS b/gdb/NEWS > index 46f6635dda0..fe91887cde4 100644 > --- a/gdb/NEWS > +++ b/gdb/NEWS > @@ -12,6 +12,35 @@ > * C expressions can now use _Alignof, and C++ expressions can now use > alignof. > > +* Changes to the "frame", "select-frame", and "info frame" CLI > + commands, as well as the "-stack-select-frame" MI command. > + Selecting frames by number remains unchanged, however, selecting > + frames by stack-address, or creating new frames now requires the use > + of a sub-command. Various sub-commands now exist for the various > + methods of selecting a frame; level, address, function, and create. > + As an example, here are the variants of "frame" that are now available: > + - frame > + - frame level > + Both of these select frame at level . > + - frame address > + Select frame for . > + - frame function > + Select inner most frame for function . > + - frame create > + Create a frame for . > + - frame create > + Create a frame for . > + There are similar variants for the "select-frame" and "info frame" > + commands. The MI command "-stack-select-frame" places the > + sub-command name after the command name as a keyword, the available > + variants are: > + -stack-select-frame > + -stack-select-frame level > + -stack-select-frame address > + -stack-select-frame function > + -stack-select-frame create > + -stack-select-frame create This is IMO too wordy for NEWS. I think it's enough to mention that new sub-command and tell that creation of new frames now requires that sub-command. > -@item frame @var{stack-addr} [ @var{pc-addr} ] > -@itemx f @var{stack-addr} [ @var{pc-addr} ] > -Select the frame at address @var{stack-addr}. This is useful mainly if the > -chaining of stack frames has been damaged by a bug, making it > -impossible for @value{GDBN} to assign numbers properly to all frames. In > -addition, this can be useful when your program has multiple stacks and > -switches between them. The optional @var{pc-addr} can also be given to > -specify the value of PC for the stack frame. > +@kindex frame address > +@item address @var{stack-address} > +Select the frame with stack address @var{stack-address}. Recall that > +each stack frame has a stack frame address, which roughly corresponds > +to the location on the stack where the stack frame local variables are > +stored. The text in the "Recall" sentence IMO doesn't convey anything useful, it just says that each frame has a stack address which can be used to select it, i.e. repeats what the previous sentence already said. > +@kindex frame create > +@item create @var{stack-address} @r{[} @var{pc-addr} @r{]} > +Create and then select a new frame at stack address @var{stack-addr}. > +This is useful mainly if the chaining of stack frames has been damaged > +by a bug, making it impossible for @value{GDBN} to assign numbers > +properly to all frames. In addition, this can be useful when your > +program has multiple stacks and switches between them. The optional > +@var{pc-addr} can also be given to specify the value of PC for the > +stack frame. I'm surprised: is it true that PC-ADDR is used only for creating new stack frames? The description refers to programs with multiple stacks, in which case I'd expect to be able to refer to existing stack frames on another stack. The original text seemed to allow that, at least implicitly. Also, is it true that damaged stack is only relevant when creating new frames? Thanks.