From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11716 invoked by alias); 5 Jun 2018 18:53:25 -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 11686 invoked by uid 89); 5 Jun 2018 18:53:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=viewing, dropped, radar, confusing X-HELO: mail-wm0-f44.google.com Received: from mail-wm0-f44.google.com (HELO mail-wm0-f44.google.com) (74.125.82.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Jun 2018 18:53:22 +0000 Received: by mail-wm0-f44.google.com with SMTP id o13-v6so6851183wmf.4 for ; Tue, 05 Jun 2018 11:53:22 -0700 (PDT) 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:in-reply-to:user-agent; bh=T+vMdjxtj47BbQZPJvwq/gjsTEk5zrjywBafRrR+zDk=; b=QGupx7KBUSnQfch/Bk4f2hLEAJGB6M8Dqv2AKi9lCbwSIpGM/5lTs7YPdUUAHypr+X LXET8Mpmv19CphERd3+bSQXzCJsWRQ/JLL6RvM75InN7sLjleP1VmqStPzW+4v/s6LHk /YzxXOEln6KcLkZ2xEstfEbImvpYVkmKHVIEb1xACIP6bYZovNkdgLrw7DREHBvOuIr2 LPkpRAS383omnaX0tCGa6pkIZpXfBqUjz51SoNxjm/n4rq+jrVGNFhhYY/E1HfRselaV wwCWtE+KBwZpls0gKhUyUT5R5WpOa6J66ezu76UDz6TD8IXO9vLsw5MqelxPpe1MLtNJ r7IA== X-Gm-Message-State: APt69E0drjwBzidT86cXYVMiyzPzAnbUeu36m39S/9cBgcXLb89fuhy+ WPqHdKBxqaZ8SEAbOEK7uXru4Q== X-Google-Smtp-Source: ADUXVKL6sgyOZ2nqNzq/Pr1Dx7sFhEbkQ3sPEOXkC65xzQo5ZQSkyArrSisy6PzYhD79Sh4kWjF5qw== X-Received: by 2002:a1c:eacd:: with SMTP id g74-v6mr204011wmi.103.1528224800451; Tue, 05 Jun 2018 11:53:20 -0700 (PDT) Received: from localhost ([159.253.162.44]) by smtp.gmail.com with ESMTPSA id u15-v6sm3238012wma.37.2018.06.05.11.53.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 05 Jun 2018 11:53:19 -0700 (PDT) Date: Tue, 05 Jun 2018 18:53:00 -0000 From: Andrew Burgess To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [PATCHv2 2/2] gdb: Change how frames are selected for 'frame' and 'info frame'. Message-ID: <20180605185318.GE15881@embecosm.com> References: <63020671a997f926cd747677cd4e614e51e81f8d.1525797846.git.andrew.burgess@embecosm.com> <83k1sanw3t.fsf@gnu.org> <20180521115357.GS3797@embecosm.com> <83y3gddl5q.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83y3gddl5q.fsf@gnu.org> 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-06/txt/msg00110.txt.bz2 Eli, Sorry for the delay in replying, this dropped off my radar for a while with other things... * Eli Zaretskii [2018-05-21 19:32:33 +0300]: > > Date: Mon, 21 May 2018 12:53:57 +0100 > > From: Andrew Burgess > > Cc: gdb-patches@sourceware.org > > > > I don't really understand what it is you're asking here, but I think > > it might be related to overloading of the word "frame", and possibly > > the keyword "create" not being a good choice. > > > > Sure, within the inferior there are a set of frames, some of these > > form the current stack, and some might exist on some alternative > > stack. Those frames exist regardless of GDB's ability to visualise > > them. > > > > However, there's a second use of the word frame, which we use for > > GDB's representation of a stack-frame. Under this second meaning the > > only frames that exist are those GDB can derive from the current > > machine state. So, if the user asks for a backtrace and is told about > > #0 A, #1 B, #2 C, then GDB only knows about those 3 frames. > > > > If the user knows of #3 D that called C (but the unwind failed for > > some reason) then they can use: 'frame create STACK-ADDR PC-ADDR' to > > "create" a suitable frame and examine the machine state. The frame > > being "created" here is really a GDB frame, that is, a representation > > of a preexisting inferior frame. > > The old text was this: > > > > > -@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. > > This seems to imply that if the frame #3 D existed, but the unwind > failed to find it, the user could say "frame STACK-ADDR PC-ADDR" to > refer to that frame. > > By contrast, your new text: > > > > > +@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. > > forces the use of "create", which is confusing, since the frame does > exist on the stack, albeit unbeknownst to GDB. > > IOW, I always thought of stack frames as existing or not independently > of whether the GDB unwinder succeeded to find them, so it's strange > for me to talk about "creating" a frame in this use case. Sure. I think our mental models for stack frames and GDB are pretty much in sync. Like I previously tried to explain the "create" here is only "creating" within GDB, not within the inferior.... > For that > matter, I don't understand why we need to force the user to type > "create" explicitly. Because, whether we call it "creating" or "viewing an existing frame that is in the inferior, but not in the backtrace", I do think that there are two _very similar_ but different actions here. One action is that the user wants to select a frame that GDB is aware of, and is part of the backtrace. The second action is that the user wants to use a $sp and $pc value to visualise a stack frame that is not part of GDB's backtrace. My assumption going into this work is that the first case (selecting by number) is what most users do, most of the time, and that the second case is much rarer. By forcing the second case to live behind a new keyword we prevent the user from accidentally visualising a new stack frame in the case where they miss-type the stack frame number. Under the new model, miss-typing a frame number would give an error. > > > Anyway, I'm happy to rework the text if you can suggest some > > improvements. Alternatively, maybe it was my choice of "create" as > > the keyword that was confusing... again, if you have any better > > suggestions I'm happy to change it, I'm not tied to "create". > > Why do we need an extra keyword, again? > > If we do need a keyword, how about "frame add"? Personally, I think 'add' is worse than 'create' - what's the frame being added too? But I do acknowledge that 'create' is not ideal either. I wonder if 'new' is better than 'create', maybe implies less "making something in the inferior"? Or how about, 'for' instead, like this: (gdb) frame for STACK-ADDR PC-ADDR Alternatively, could this problem be solved by a better description in the manual, maybe something like this: Create within GDB a representation of a stack frame that is not part of the current backtrace. The newly created frame has a stack address @var{stack-addr}, and an optional program counter address @var{pc-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. Thanks for all your help reviewing this patch. Andrew