Re: [PATCH] Add temporary frames to frame cache.

[Pedro Alves <palves at redhat dot com>]

On 06/07/2013 03:36 PM, Andrew Burgess wrote:
> Found the following issue,
> 
> ## START ##
> (gdb) break break_me 
> Breakpoint 1 at 0x400738: file ../../../src/gdb/testsuite/gdb.base/frame-args.c, line 35.
> (gdb) r
> Starting program: /projects/firepath_work/aburgess/upstream-gdb-git/build/gdb/testsuite/gdb.base/frame-args 
> 
> Breakpoint 1, break_me ()
>     at ../../../src/gdb/testsuite/gdb.base/frame-args.c:35
> 35      }
> (gdb) bt
> #0  break_me () at ../../../src/gdb/testsuite/gdb.base/frame-args.c:35
> #1  0x000000000040075e in call_me (i=3, f=5, s=..., ss=0x7fffffffdef0, u=..., 
>     e=green) at ../../../src/gdb/testsuite/gdb.base/frame-args.c:40
> #2  0x00000000004007a3 in main ()
>     at ../../../src/gdb/testsuite/gdb.base/frame-args.c:53
> (gdb) frame 3
> #0  0x0000000000000000 in ?? ()
> (gdb) info frame
> Stack level 0, frame at 0x3:
>  rip = 0x0; saved rip 0x7fffffffded0
>  called by frame at 0x7fffffffdeb0
>  Arglist at 0x7fffffffde98, args: 
>  Locals at 0x7fffffffde98, Previous frame's sp is 0x7fffffffdea8
> ../../src/gdb/valops.c:1025: internal-error: value_fetch_lazy: Assertion `frame != NULL' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n) y
> ## END ##
> 
> This is because when I do "frame 3" a new frame is created with a call
> to create_new_frame at the end of parse_frame_specification_1.  However,
> in value_fetch_lazy the frame can't be found again.
> My solution is to add the new frame to the frame cache from within
> create_new_frame, this fixes the issue and shows no regressions on x86-64
> Linux.

There's a create_new_frame call in mn10300_push_dummy_call
which creates an on-the-side frame that really shouldn't be in
the frame chain or stash, so registering this new frame in the
stack/stash should be done by callers (the fact that the function's
interface returns a frame pointer instead of putting the frame on
the stack itself should be another indication that that is the
right way to do such an adjustment).

"info frame 3" should not leave the new frame on the stash.
To fix that I suggest making the new frame the current_frame
while "info frame" is running" (call reinit_frame_cache first),
and reverting back to the previously selected frame afterwards,
with a cleanup.

(BTW, I find the fact that "frame NUMBER" can create a new frame to
be really a bad interface, and very confusing for users.  I'd
much rather the command would error out if the frame is not found
(as most frequently that'll be a user mistake), and the user that
really knows what she's doing and wants to inspect stack at
some address, would instead do something like
"frame -create ADDRESS" to create a new frame at a random address.
The implementation of that would indeed then install this new
frame as current_frame, and so "bt" from there would start
unwinding from ADDRESS.  The documentation could then also
document how to get out of this frame in order to start unwinding
from the current registers again.  E.g., pointing at "flushregs".)

-- 
Pedro Alves