Re: How frame command with address works

Thanks for your answer. I tried frame view on an intact callstack that works with bt for test purposes:

(gdb) f 2
#2  0x0000007f9eaa2c68 someFunc (this=0x3a015370, timeout=4294967295, selector=0x0)
    at <sourcecode>
(gdb) p $sp
$20 = (void *) 0x7f9c256630
(gdb) p $pc
$21 = (void (*)(void)) 0x7f9eaa2c68
(gdb) frame view 0x7f9c256630 0x7f9eaa2c68
#0  0x0000007f9eaa2c68 in somefunc (this=0x3a01540c, timeout=1,
    selector=0x7f9eaa2be0 )
    at <sourcecode>

It can be seen that the this pointer is different from the frame view result. It always is 0x3a01540c regardless on how I set the stack pointer or program counter.
It seems to me that while it sets the pc correctly it pulls the args always from frame 0.

________________________________
From: Simon Marchi <[email protected]>
Sent: Wednesday, February 8, 2023 9:50 PM
To: Roger Phillips <[email protected]>; [email protected] <[email protected]>
Subject: Re: How frame command with address works



On 2/8/23 05:01, Roger Phillips via Gdb wrote:
> Greetings,
>
> I have to analyze a coredump on an Aarch64 system. The callstack is
> broken so I only see the bottom frame. However, if I manually unwind
> the stack via $x29 register then I see what looks like intact stack
> frames. Now I try to use the frame / frame address command with the
> addresses from the $x29 registers which should point to the bases of
> the stackframes (the location where the address of the next frame is).
> However it always tells me "No frame at address ...".
>
> What does frame address need to correctly parse a frame?

I think you want to use the "frame view" or "select-frame view"
command, which lets you specify arbitrary SP and PC addresses.  GDB
makes a frame_info object out of those and shows it to you.

It used to be that "frame <ADDRESS>" would do that, but it was
error-prone, as explained here, so was chanted to "frame view" and
"select-frame view":

  https://gitlab.com/gnutools/binutils-gdb/-/commit/f67ffa6a785bee26bc23550670f85c6db578641f

I know a bit about that feature because it was in the way of some change
I wanted to do recently (frame_info_ptr, if someone wants to search the
git log).  I think the intent of the feature is exactly your scenario.
However, I'm under the impression that it's a bit broken right now.
When selecting an arbitrary frame with "select-frame view", you can't do
up/down to see callers of that frame, and "backtrace" shows you the
"real" stack.  I've been told that these commands used to work with
user-created frames though, probably a long time ago.  But since that
feature wasn't tested at all, I guess it got broken.

Simon