How frame command with address works

How frame command with address works

[Roger Phillips]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

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?

Regards

Re: How frame command with address works

[Simon Marchi]

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

Re: How frame command with address works

[Roger Phillips]

[-- Attachment #1: Type: text/plain, Size: 2692 bytes --]

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 <simark@simark.ca>
Sent: Wednesday, February 8, 2023 9:50 PM
To: Roger Phillips <heidegg@hotmail.com>; gdb@sourceware.org <gdb@sourceware.org>
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

Re: How frame command with address works

[Simon Marchi]

On 2/9/23 05:43, Roger Phillips wrote:
> 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.

This is probably because GDB reads registers from the current target,
when viewing a user-created frame.  Yeah, it's odd, and part of why I
find that feature a bit strange.

Simon