Re: [PATCHv2 2/2] gdb: Change how frames are selected for 'frame' and 'info frame'.

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Mon, 21 May 2018 12:53:57 +0100
> From: Andrew Burgess <andrew.burgess@embecosm.com>
> 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.  For that
matter, I don't understand why we need to force the user to type
"create" explicitly.

> 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"?