info frame

info frame

[Nick Roberts]

'info frame' says that the frame is at a different address (0xbffff710)
to $fp (0xbffff708).  This wasn't the case with older versions e.g 5.2.1:

  nickrob/31  gdb myprog
  GNU gdb 5.2.1-2mdk (Mandrake Linux)
  Copyright 2002 Free Software Foundation, Inc.
  ...
  (gdb) inf frame
  Stack level 0, frame at 0xbffff728:
   eip = 0x80484a9 in main (myprog.c:47); saved eip 0x4006015a
   called by frame at 0xbffff768
   source language c.
   Arglist at 0xbffff728, args: argc=1, argv=0xbffff794
   Locals at 0xbffff728, Previous frame's sp is 0x0
   Saved registers:
    ebp at 0xbffff728, eip at 0xbffff72c
  (gdb) p $fp
  $1 = (void *) 0xbffff728

  nickrob/32 src/gdb/gdb myprog
  GNU gdb 6.4.50.20060405-cvs
  Copyright (C) 2006 Free Software Foundation, Inc.
  ...
  (gdb) info frame
  Stack level 0, frame at 0xbffff710:
   eip = 0x80484a9 in main (myprog.c:47); saved eip 0x4006015a
   source language c.
   Arglist at 0xbffff708, args: argc=1, argv=0xbffff774
   Locals at 0xbffff708, Previous frame's sp is 0xbffff710
   Saved registers:
    ebp at 0xbffff708, eip at 0xbffff70c
  (gdb) p $fp
  $1 = (void *) 0xbffff708

Can this be right?


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: info frame

[Mark Kettenis]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Mon, 17 Apr 2006 11:15:45 +1200
> 
> 'info frame' says that the frame is at a different address (0xbffff710)
> to $fp (0xbffff708).  This wasn't the case with older versions e.g 5.2.1:
> 
>   nickrob/31  gdb myprog
>   GNU gdb 5.2.1-2mdk (Mandrake Linux)
>   Copyright 2002 Free Software Foundation, Inc.
>   ...
>   (gdb) inf frame
>   Stack level 0, frame at 0xbffff728:
>    eip = 0x80484a9 in main (myprog.c:47); saved eip 0x4006015a
>    called by frame at 0xbffff768
>    source language c.
>    Arglist at 0xbffff728, args: argc=1, argv=0xbffff794
>    Locals at 0xbffff728, Previous frame's sp is 0x0
>    Saved registers:
>     ebp at 0xbffff728, eip at 0xbffff72c
>   (gdb) p $fp
>   $1 = (void *) 0xbffff728
> 
>   nickrob/32 src/gdb/gdb myprog
>   GNU gdb 6.4.50.20060405-cvs
>   Copyright (C) 2006 Free Software Foundation, Inc.
>   ...
>   (gdb) info frame
>   Stack level 0, frame at 0xbffff710:
>    eip = 0x80484a9 in main (myprog.c:47); saved eip 0x4006015a
>    source language c.
>    Arglist at 0xbffff708, args: argc=1, argv=0xbffff774
>    Locals at 0xbffff708, Previous frame's sp is 0xbffff710
>    Saved registers:
>     ebp at 0xbffff708, eip at 0xbffff70c
>   (gdb) p $fp
>   $1 = (void *) 0xbffff708
> 
> Can this be right?

Yes, current GDB uses the convention that the frame address is the
Canonical Frame Address (CFA) as used by the DWARF 2 Call Frame Info
(CFI).  In general the CFA is the value of the stack pointer when the
current function was called.  Since on i386 the "call" instruction
pushes the return address on the stack, and the "standard" prologue:

push %ebp
mov %esp,%ebp

pushes another 32-bit word onto the stack, which gives the offset
0xbffff710 - 0xbffff708 = 8 that you're seeing.

Note that while %ebp is usually used as a frame pointer register, the
architecture doesn't actually force you to do that.  Nowadays
compilers can and will generate frameless functions, and for those,
the value %ebp is meaningless.

Mark

Re: info frame

[Nick Roberts]

 ...
 > Note that while %ebp is usually used as a frame pointer register, the
 > architecture doesn't actually force you to do that.  Nowadays
 > compilers can and will generate frameless functions, and for those,
 > the value %ebp is meaningless.

Thanks for the explanation.  

Does this mean that if we choose to print the frame address in MI as part
of the output of -stack-list-frames:

>> Can somebody suggest the right fix? So far, I think that the simplest
>> approach is to make gdb print stack address of current frame, like  
>> is done
>> on the Apple branch:
>>
>>      553^done,stack=[frame=
>>      {level="0",addr="0x00003db0",fp="0xbffff2c0",......

0xbffff2c0 should not be the value of $fp but the value of "frame at..." in
'info frame`?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: info frame

[Daniel Jacobowitz]

On Mon, Apr 17, 2006 at 12:37:23PM +1200, Nick Roberts wrote:
> Does this mean that if we choose to print the frame address in MI as part
> of the output of -stack-list-frames:
> 
> >> Can somebody suggest the right fix? So far, I think that the simplest
> >> approach is to make gdb print stack address of current frame, like  
> >> is done
> >> on the Apple branch:
> >>
> >>      553^done,stack=[frame=
> >>      {level="0",addr="0x00003db0",fp="0xbffff2c0",......
> 
> 0xbffff2c0 should not be the value of $fp but the value of "frame at..." in
> 'info frame`?

In fact, it's like that it will be the "frame at" address.  But I don't
think it would be wise to architect that into the interface; I think I
explained why earlier, but if not, it's because this is a touchy
internal interface for GDB.  If you want to display it to the user, you
might want something different - either explicitly the $sp, or
explictly the architectural $fp register, or explicitly the call frame
address.  If you want to use it in a frontend, then all we should offer
is an opaque ID for equality testing, IMHO.

If GDB changes its internal representation we shouldn't have to update
frontends.

-- 
Daniel Jacobowitz
CodeSourcery

Re: info frame

[Nick Roberts]

 > > >>      553^done,stack=[frame=
 > > >>      {level="0",addr="0x00003db0",fp="0xbffff2c0",......
 > > 
 > > 0xbffff2c0 should not be the value of $fp but the value of "frame at..." in
 > > 'info frame`?
 > 
 > In fact, it's like that it will be the "frame at" address.  But I don't
 > think it would be wise to architect that into the interface; I think I
 > explained why earlier, but if not, it's because this is a touchy
 > internal interface for GDB.  If you want to display it to the user, you
 > might want something different - either explicitly the $sp, or
 > explictly the architectural $fp register, or explicitly the call frame
 > address.  If you want to use it in a frontend, then all we should offer
 > is an opaque ID for equality testing, IMHO.
 > 
 > If GDB changes its internal representation we shouldn't have to update
 > frontends.

I don't think it matters if the internal representation does change, so long as
its self consistent.  As I mentioned before Totalview displays the fp address
of each frame in the call stack.  It also displays the appropriate fp address
in the window of each watch expression (each expression has its own window).
That way, the fp address does act as an ID for the frame and the user can
easily see which frame the watch expression belongs to, but its actual value is
generally not of interest.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: info frame

[Eli Zaretskii]

> Date: Sun, 16 Apr 2006 21:33:43 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, gdb@sources.redhat.com
> 
> > >>      553^done,stack=[frame=
> > >>      {level="0",addr="0x00003db0",fp="0xbffff2c0",......
> > 
> > 0xbffff2c0 should not be the value of $fp but the value of "frame at..." in
> > 'info frame`?
> 
> In fact, it's like that it will be the "frame at" address.

Daniel, I cannot parse this sentence, and consequently I cannot figure
out what are you saying in general.

> But I don't
> think it would be wise to architect that into the interface; I think I
> explained why earlier, but if not, it's because this is a touchy
> internal interface for GDB.  If you want to display it to the user, you
> might want something different - either explicitly the $sp, or
> explictly the architectural $fp register, or explicitly the call frame
> address.  If you want to use it in a frontend, then all we should offer
> is an opaque ID for equality testing, IMHO.

Are you saying that the "frame at ..." part in the CLI output is
meaningless for users?  If so, why do we show it at all?

Re: info frame

[Vladimir Prus]

Eli Zaretskii wrote:

>> Date: Sun, 16 Apr 2006 21:33:43 -0400
>> From: Daniel Jacobowitz <drow@false.org>
>> Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, gdb@sources.redhat.com
>> 
>> > >>      553^done,stack=[frame=
>> > >>      {level="0",addr="0x00003db0",fp="0xbffff2c0",......
>> > 
>> > 0xbffff2c0 should not be the value of $fp but the value of "frame
>> > at..." in 'info frame`?
>> 
>> In fact, it's like that it will be the "frame at" address.
> 
> Daniel, I cannot parse this sentence, and consequently I cannot figure
> out what are you saying in general.
> 
>> But I don't
>> think it would be wise to architect that into the interface; I think I
>> explained why earlier, but if not, it's because this is a touchy
>> internal interface for GDB.  If you want to display it to the user, you
>> might want something different - either explicitly the $sp, or
>> explictly the architectural $fp register, or explicitly the call frame
>> address.  If you want to use it in a frontend, then all we should offer
>> is an opaque ID for equality testing, IMHO.
> 
> Are you saying that the "frame at ..." part in the CLI output is
> meaningless for users?  If so, why do we show it at all?

Well, "info frame" is documented to print absolutely all information about a
frame. And frame base address is part of "all information".

I would not want that field to go away, at least not until frame id is
exposed via some other command.

- Volodya

Re: info frame

[Daniel Jacobowitz]

On Mon, Apr 17, 2006 at 10:16:43AM +0300, Eli Zaretskii wrote:
> > Date: Sun, 16 Apr 2006 21:33:43 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, gdb@sources.redhat.com
> > 
> > > >>      553^done,stack=[frame=
> > > >>      {level="0",addr="0x00003db0",fp="0xbffff2c0",......
> > > 
> > > 0xbffff2c0 should not be the value of $fp but the value of "frame at..." in
> > > 'info frame`?
> > 
> > In fact, it's like that it will be the "frame at" address.
> 
> Daniel, I cannot parse this sentence, and consequently I cannot figure
> out what are you saying in general.

Replace like with likely and it has slightly more intelligible grammar.

> > But I don't
> > think it would be wise to architect that into the interface; I think I
> > explained why earlier, but if not, it's because this is a touchy
> > internal interface for GDB.  If you want to display it to the user, you
> > might want something different - either explicitly the $sp, or
> > explictly the architectural $fp register, or explicitly the call frame
> > address.  If you want to use it in a frontend, then all we should offer
> > is an opaque ID for equality testing, IMHO.
> 
> Are you saying that the "frame at ..." part in the CLI output is
> meaningless for users?  If so, why do we show it at all?

It isn't completely meaningless.  However, it's highly system specific,
and (as Nick noticed) it has changed before.

-- 
Daniel Jacobowitz
CodeSourcery

Re: info frame

[Eli Zaretskii]

> Date: Mon, 17 Apr 2006 08:26:06 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, gdb@sources.redhat.com,
> 	nickrob@snap.net.nz
> 
> On Mon, Apr 17, 2006 at 10:16:43AM +0300, Eli Zaretskii wrote:
> > > Date: Sun, 16 Apr 2006 21:33:43 -0400
> > > From: Daniel Jacobowitz <drow@false.org>
> > > Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, gdb@sources.redhat.com
> > > 
> > > > >>      553^done,stack=[frame=
> > > > >>      {level="0",addr="0x00003db0",fp="0xbffff2c0",......
> > > > 
> > > > 0xbffff2c0 should not be the value of $fp but the value of "frame at..." in
> > > > 'info frame`?
> > > 
> > > In fact, it's like that it will be the "frame at" address.
> > 
> > Daniel, I cannot parse this sentence, and consequently I cannot figure
> > out what are you saying in general.
> 
> Replace like with likely and it has slightly more intelligible grammar.

It does, thanks.

> > Are you saying that the "frame at ..." part in the CLI output is
> > meaningless for users?  If so, why do we show it at all?
> 
> It isn't completely meaningless.  However, it's highly system specific,

Mark seemed to say something different: that it's quite consistent.

If it has no well-defined meaning, perhaps we should move it to some
maint command.

Re: info frame

[Eli Zaretskii]

> Date: Mon, 17 Apr 2006 01:33:21 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: gdb@sources.redhat.com
> 
> >   (gdb) info frame
> >   Stack level 0, frame at 0xbffff710:
> >    eip = 0x80484a9 in main (myprog.c:47); saved eip 0x4006015a
> >    source language c.
> >    Arglist at 0xbffff708, args: argc=1, argv=0xbffff774
> >    Locals at 0xbffff708, Previous frame's sp is 0xbffff710
> >    Saved registers:
> >     ebp at 0xbffff708, eip at 0xbffff70c
> >   (gdb) p $fp
> >   $1 = (void *) 0xbffff708
> > 
> > Can this be right?
> 
> Yes, current GDB uses the convention that the frame address is the
> Canonical Frame Address (CFA) as used by the DWARF 2 Call Frame Info
> (CFI).

Does this mean that, if the debug info is stabs or something other
than DWARF 2, a different frame address will be displayed for the same
code?

> In general the CFA is the value of the stack pointer when the
> current function was called.

``In general''?  Does this mean that in some cases it will be
something else?  If so, when that will happen, and what will we show
then?

I'm asking all this because it should be somehow mentioned in the
docs.

TIA

Re: info frame

[Mark Kettenis]

> Date: Mon, 17 Apr 2006 10:05:50 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Mon, 17 Apr 2006 01:33:21 +0200 (CEST)
> > From: Mark Kettenis <mark.kettenis@xs4all.nl>
> > CC: gdb@sources.redhat.com
> > 
> > >   (gdb) info frame
> > >   Stack level 0, frame at 0xbffff710:
> > >    eip = 0x80484a9 in main (myprog.c:47); saved eip 0x4006015a
> > >    source language c.
> > >    Arglist at 0xbffff708, args: argc=1, argv=0xbffff774
> > >    Locals at 0xbffff708, Previous frame's sp is 0xbffff710
> > >    Saved registers:
> > >     ebp at 0xbffff708, eip at 0xbffff70c
> > >   (gdb) p $fp
> > >   $1 = (void *) 0xbffff708
> > > 
> > > Can this be right?
> > 
> > Yes, current GDB uses the convention that the frame address is the
> > Canonical Frame Address (CFA) as used by the DWARF 2 Call Frame Info
> > (CFI).
> 
> Does this mean that, if the debug info is stabs or something other
> than DWARF 2, a different frame address will be displayed for the same
> code?

No.  All the different unwinders use the same convention.  This is
exactly why the convention changed on i386 when the DWARF 2 unwinder
was introduced: to make the fallback unwinder match the DWARF 2
unwinder.

> > In general the CFA is the value of the stack pointer when the
> > current function was called.
> 
> ``In general''?  Does this mean that in some cases it will be
> something else?  If so, when that will happen, and what will we show
> then?

DWARF 2 doesn't specify exactly what the convention is.  So most ISA's
use the convention above, but other ISA's might use a different
convention.

Also different compilers for the same ISA might use different
conventions when they generate DWARF 2 debug information.  In that
case you're screwed because the CFA returned from the DWARF 2 unwinder
will no longer match the convention used by GDB's other unwinders.  So
far we haven't seen any other compilers that use a different
convention, so things are safe for now.

Mark

Re: info frame

[Eli Zaretskii]

> Date: Mon, 17 Apr 2006 10:58:43 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: nickrob@snap.net.nz, gdb@sources.redhat.com
> 
> > > Yes, current GDB uses the convention that the frame address is the
> > > Canonical Frame Address (CFA) as used by the DWARF 2 Call Frame Info
> > > (CFI).
> > 
> > Does this mean that, if the debug info is stabs or something other
> > than DWARF 2, a different frame address will be displayed for the same
> > code?
> 
> No.  All the different unwinders use the same convention.

Don't you glean the information from the debug info?  At least for
functions that violate the normal call frame, you probably must, no?

Re: info frame

[Mark Kettenis]

> X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on 
> 	elgar.sibelius.xs4all.nl
> X-Spam-Level: 
> X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
> 	version=3.1.0
> Date: Mon, 17 Apr 2006 13:35:54 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> CC: nickrob@snap.net.nz, gdb@sources.redhat.com
> Reply-to: Eli Zaretskii <eliz@gnu.org>
> X-IsSubscribed: yes
> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
> Sender: gdb-owner@sourceware.org
> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information.
> X-UTwente-MailScanner: Found to be clean
> X-MailScanner-From: gdb-return-24948-m.m.kettenis=alumnus.utwente.nl@sourceware.org
> X-XS4ALL-DNSBL-Checked: mxdrop40.xs4all.nl checked 192.87.17.19 against DNS blacklists
> X-Virus-Scanned: by XS4ALL Virus Scanner
> X-XS4ALL-Spam-Score: 0 () 
> X-XS4ALL-Spam: NO
> Envelope-To: mark.kettenis@xs4all.nl
> X-UIDL: 1145270175._smtp.mxdrop40.36794,S=3326
> 
> > Date: Mon, 17 Apr 2006 10:58:43 +0200 (CEST)
> > From: Mark Kettenis <mark.kettenis@xs4all.nl>
> > CC: nickrob@snap.net.nz, gdb@sources.redhat.com
> > 
> > > > Yes, current GDB uses the convention that the frame address is the
> > > > Canonical Frame Address (CFA) as used by the DWARF 2 Call Frame Info
> > > > (CFI).
> > > 
> > > Does this mean that, if the debug info is stabs or something other
> > > than DWARF 2, a different frame address will be displayed for the same
> > > code?
> > 
> > No.  All the different unwinders use the same convention.
> 
> Don't you glean the information from the debug info?  At least for
> functions that violate the normal call frame, you probably must, no?

The only debug format that contains the information is DWARF 2/3.  The
other unwinders all code scanning techniques to find out the CFA.
Those have been adapted to match the CFA as used by GCC.