info frame

'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.n
z/~nickrob

> From: Nick Roberts <nickrobsnap.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

 ...
 > 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=&qu
ot;0xbffff2c0",......

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

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

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=&qu
ot;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

 > > >>      553^done,stack=[frame=
 > > >>     
{level="0",addr="0x00003db0",fp=&qu
ot;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.n
z/~nickrob

> Date: Mon, 17 Apr 2006 01:33:21 +0200 (CEST)
> From: Mark Kettenis <mark.kettenisxs4all.nl>
> CC: gdbsources.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

> Date: Sun, 16 Apr 2006 21:33:43 -0400
> From: Daniel Jacobowitz <drowfalse.org>
> Cc: Mark Kettenis <mark.kettenisxs4all.nl>, gdbsources.redhat.com
> 
> > >>      553^done,stack=[frame=
> > >>     
{level="0",addr="0x00003db0",fp=&qu
ot;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?

> Date: Mon, 17 Apr 2006 10:05:50 +0300
> From: Eli Zaretskii <elizgnu.org>
> 
> > Date: Mon, 17 Apr 2006 01:33:21 +0200 (CEST)
> > From: Mark Kettenis <mark.kettenisxs4all.nl>
> > CC: gdbsources.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

> Date: Mon, 17 Apr 2006 10:58:43 +0200 (CEST)
> From: Mark Kettenis <mark.kettenisxs4all.nl>
> CC: nickrobsnap.net.nz, gdbsources.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?

> 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 <elizgnu.org>
> CC: nickrobsnap.net.nz, gdbsources.redhat.com
> Reply-to: Eli Zaretskii <elizgnu.org>
> X-IsSubscribed: yes
> Mailing-List: contact gdb-helpsourceware.org; run by
ezmlm
> Sender: gdb-ownersourceware.org
> X-UTwente-MailScanner-Information: Scanned by
MailScanner. Contact helpdeskITBE.utwente.nl for more
information.
> X-UTwente-MailScanner: Found to be clean
> X-MailScanner-From:
gdb-return-24948-m.m.kettenis=alumnus.utwente.nlsourceware.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.kettenisxs4all.nl
> X-UIDL: 1145270175._smtp.mxdrop40.36794,S=3326
> 
> > Date: Mon, 17 Apr 2006 10:58:43 +0200 (CEST)
> > From: Mark Kettenis <mark.kettenisxs4all.nl>
> > CC: nickrobsnap.net.nz, gdbsources.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.