Specify frame by address

Specify frame by address

[Eli Zaretskii]

Both the doc string of the "frame" command and the manual say that it
accepts frame specification by address:

  (gdb) help frame
  Select and print a stack frame.
  With no argument, print the selected stack frame.  (See also "info frame").
  An argument specifies the frame to select.
  It can be a stack frame number or the address of the frame.  <<<<<<<<<<
  With argument, nothing is printed if input is coming from
  a command file or a user-defined command.

But what is "the address of the frame"?  I thought that using an
address of a function (the one shown by "info address") or some
address shown by the "backtrace" command would do, but none of them
seems to work.

What am I missing?

The context of this is that I would like to write a command that
automatically goes to a frame within a call to a specific function,
because that command needs to access variables local to that function.

TIA

Re: Specify frame by address

[Jan Kratochvil]

Hi Eli,

On Sat, 29 Oct 2011 19:12:36 +0200, Eli Zaretskii wrote:
>   An argument specifies the frame to select.
>   It can be a stack frame number or the address of the frame.  <<<<<<<<<<
>   With argument, nothing is printed if input is coming from
>   a command file or a user-defined command.
> 
> But what is "the address of the frame"?  I thought that using an
> address of a function (the one shown by "info address") or some
> address shown by the "backtrace" command would do, but none of them
> seems to work.

See the bottom of parse_frame_specification_1.

"address of the frame" is frame_id.stack_addr.  For DWARF it is CFA
(dwarf2_frame_cfa), which is for most arches just unwound SP (not PC!), that
is SP as shown by GDB in the caller.

(gdb) info frame
Stack level 5, frame at 0x7fffffffd880:
[...]
(gdb) up
#6  0x0000000000486e82 in captured_command_loop (data=0x0) at ./main.c:234
(gdb) p/x $sp
$1 = 0x7fffffffd880
(gdb) frame 0
(gdb) frame 0x7fffffffd880
#5  0x00000000006f1421 in current_interp_command_loop () at interps.c:309


> The context of this is that I would like to write a command that
> automatically goes to a frame within a call to a specific function,
> because that command needs to access variables local to that function.

Such command really needs to iterate the frames and compare PC there.


Regards,
Jan

Re: Specify frame by address

[Eli Zaretskii]

> Date: Sat, 29 Oct 2011 19:46:38 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb@sourceware.org
> 
> "address of the frame" is frame_id.stack_addr.  For DWARF it is CFA
> (dwarf2_frame_cfa), which is for most arches just unwound SP (not PC!), that
> is SP as shown by GDB in the caller.

Thanks.

What is it for stabs?  More generally, suppose I wanted to make the
manual more clear on this matter, what could I tell the user about
how to find out this address?

> Such command really needs to iterate the frames and compare PC there.

Right.  I hoped that I could reference the frame by the PC address.

Re: Specify frame by address

[Mark Kettenis]

> Date: Sat, 29 Oct 2011 20:02:42 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Sat, 29 Oct 2011 19:46:38 +0200
> > From: Jan Kratochvil <jan.kratochvil@redhat.com>
> > Cc: gdb@sourceware.org
> > 
> > "address of the frame" is frame_id.stack_addr.  For DWARF it is CFA
> > (dwarf2_frame_cfa), which is for most arches just unwound SP (not PC!), that
> > is SP as shown by GDB in the caller.
> 
> Thanks.
> 
> What is it for stabs?  More generally, suppose I wanted to make the
> manual more clear on this matter, what could I tell the user about
> how to find out this address?

The debug info format isn't really relevant.  It's the architecture
that matters.  The address is typically the value of the stack pointer
just before doing the function call, or the value of the stack pointer
upon function entry.  We try to make sure that all unwinders agree on
the convention used, which is why for most architectures we use the
same convention as used by GCC for calculating the DWARF CFA, such
that the architecture-independent DWARF unwinder uses the same
convention as the architecture-specific unwinders that are used if no
DWARF debug info is available.

The frame address is printed by the "info frame":

Breakpoint 1, 0x000000000042b910 in main ()
(gdb) info frame
Stack level 0, frame at 0x7f7ffffbc350:
 rip = 0x42b910 in main; saved rip 0x42b761
 Arglist at 0x7f7ffffbc340, args: 
 Locals at 0x7f7ffffbc340, Previous frame's sp is 0x7f7ffffbc350
 Saved registers:
  rip at 0x7f7ffffbc348

So on amd64 the convention is that the frame address is the stack
pointer before the function call was made.

> > Such command really needs to iterate the frames and compare PC there.
> 
> Right.  I hoped that I could reference the frame by the PC address.

That wouldn't work.  Functions are sometimes called recursively, so
diffrerent frames may end up with the same PC address.

Re: Specify frame by address

[Jan Kratochvil]

On Sat, 29 Oct 2011 20:43:25 +0200, Mark Kettenis wrote:
> > What is it for stabs?  More generally, suppose I wanted to make the
> > manual more clear on this matter, what could I tell the user about
> > how to find out this address?
> 
> The debug info format isn't really relevant.  It's the architecture
> that matters.

If the debug info provides its own unwinder - such as DWARF does - the
architecture does not matter as it gets fully handled by dwarf2-frame.c.
It is true anything besides DWARF - like STABS - just falls back to the
architecture unwinder.


Regards,
Jan

Re: Specify frame by address

[Mark Kettenis]

> Date: Sat, 29 Oct 2011 20:48:08 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> 
> On Sat, 29 Oct 2011 20:43:25 +0200, Mark Kettenis wrote:
> > > What is it for stabs?  More generally, suppose I wanted to make the
> > > manual more clear on this matter, what could I tell the user about
> > > how to find out this address?
> > 
> > The debug info format isn't really relevant.  It's the architecture
> > that matters.
> 
> If the debug info provides its own unwinder - such as DWARF does - the
> architecture does not matter as it gets fully handled by dwarf2-frame.c.

I know how the code works; I wrote significant parts of it.  The
architecture does matter, since the convention for what stack address
to use as the CFA depends on the architecture.

> It is true anything besides DWARF - like STABS - just falls back to the
> architecture unwinder.

And that is why the DWARF unwinder and the architecture unwinders
should use the same convention.  So far we've always adjusted the
architecture unwinders to match he DWARF unwinder as that was easiest
and the DWARF CFA turned out to be a meaningful address on those
architectures.  But if that turns out not to be the case for some
future architecture we will have to add a gdbarch method for the DWARF
unwinder to call that fixes things up.

Re: Specify frame by address

[Yao Qi]

On 10/30/2011 06:07 PM, Mark Kettenis wrote:
>> > If the debug info provides its own unwinder - such as DWARF does - the
>> > architecture does not matter as it gets fully handled by dwarf2-frame.c.
> I know how the code works; I wrote significant parts of it.  The
> architecture does matter, since the convention for what stack address
> to use as the CFA depends on the architecture.
> 

Mark,
could you elaborate the "convention for what stack address to use as the
CFA"?  Is this "convention" about "CFA is usually defined by the value
of SP"? and $PORT_dwarf2_frame_init_reg is to define some more or
different.

-- 
Yao (齐尧)

Re: Specify frame by address

[Eli Zaretskii]

> Date: Sat, 29 Oct 2011 20:43:25 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: jan.kratochvil@redhat.com, gdb@sourceware.org
> 
> > I hoped that I could reference the frame by the PC address.
> 
> That wouldn't work.  Functions are sometimes called recursively, so
> diffrerent frames may end up with the same PC address.

That's not a problem in my use case, because I need the innermost
invocation anyway.

Thanks for the other info.

Re: Specify frame by address

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Both the doc string of the "frame" command and the manual say that it
> accepts frame specification by address:
>
>   (gdb) help frame
>   Select and print a stack frame.
>   With no argument, print the selected stack frame.  (See also "info frame").
>   An argument specifies the frame to select.
>   It can be a stack frame number or the address of the frame.  <<<<<<<<<<
>   With argument, nothing is printed if input is coming from
>   a command file or a user-defined command.
>
> But what is "the address of the frame"?

What info frame would display (typically the stack pointer on entry).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Specify frame by address

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: gdb@sourceware.org
> Date: Sat, 29 Oct 2011 20:04:34 +0200
> 
> > But what is "the address of the frame"?
> 
> What info frame would display (typically the stack pointer on entry).

Thanks.

Re: Specify frame by address

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> The context of this is that I would like to write a command that
Eli> automatically goes to a frame within a call to a specific function,
Eli> because that command needs to access variables local to that function.

If you use "gdb --dbx" then the "func" command will select a frame given
the name of the function.

I wouldn't be averse to giving this command a different name and making
it always available.  We'll probably do something like this, maybe more
DWIMy though, as part of the frame filter project, like a generalized
"upto" for those who remember from the archer list.

Tom

Re: Specify frame by address

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: gdb@sourceware.org
> Date: Tue, 01 Nov 2011 12:58:28 -0600
> 
> If you use "gdb --dbx" then the "func" command will select a frame given
> the name of the function.
> 
> I wouldn't be averse to giving this command a different name and making
> it always available.

Yes, it sounds like a useful feature in general.

Thanks.