Re: [RFC] "info registers" is misleading

Re: [RFC] "info registers" is misleading

[Michael Elizabeth Chastain]

FYI, as an aside: you can make the URL a lot shorter by dropping the
"return_url=" parameter.

  http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=251

That's what I do when I want to link to a gnats report.

Michael C

[RFC] "info registers" is misleading

[Fred Fish]

I had always thought that "info registers" is supposed to tell you 
the actual register contents, and is simply a convenient way to see
all the registers with one command.  I.E. it is equivalent to
doing something like:

	(gdb) p/x $r0
	(gdb) p/x $r1
	...

While chasing a bug in some THUMB code related to the stack not being
restored correctly when using the "return xxx" command, I stumbled
over a case where "info registers" prints the value of r11 differently
than "p/x $r11" does.

  Script started on Mon Jan 21 23:33:14 2002

  $ cat bug.c
  #include <stdio.h>
  
  int
  callee2 (int n)
  {
    return 0;
  }
  
  int
  callee1 (void)
  {
    int n = 1;
    n = callee2 (n);
    return n;
  }
  
  int main ()
  {
    callee1 ();
  }

  $ arm-elf-gcc -mthumb -g -o bug bug.c

  $ ./gdb-orig -nw -nx bug
  GNU gdb 2002-01-22-cvs
  Copyright 2002 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you are
  welcome to change it and/or distribute copies of it under certain conditions.
  Type "show copying" to see the conditions.
  There is absolutely no warranty for GDB.  Type "show warranty" for details.
  This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf"...
  (gdb) tar sim
  Connected to the simulator.
  (gdb) load
  Loading section .init, size 0x14 vma 0x8000
  Loading section .text, size 0x1570 vma 0x8014
  Loading section .fini, size 0x10 vma 0x9584
  Loading section .rodata, size 0x8 vma 0x9594
  Loading section .data, size 0x84c vma 0x969c
  Loading section .eh_frame, size 0x4 vma 0x9ee8
  Loading section .ctors, size 0x8 vma 0x9eec
  Loading section .dtors, size 0x8 vma 0x9ef4
  Loading section .jcr, size 0x4 vma 0x9efc
  Start address 0x80cc
  Transfer rate: 61440 bits in <1 sec.
  (gdb) br callee2
  Breakpoint 1 at 0x81ae: file bug.c, line 6.
  (gdb) run
  Starting program: /build/sourceware/gdb/H-i686-pc-linux-gnu/T-arm-elf/gdb/bug 
  
  Breakpoint 1, callee2 (n=1) at bug.c:6
  6	  return 0;
  (gdb) info reg
  r0             0x1	1
  r1             0x1ffffc	2097148
  r2             0x1fffe8	2097128
  r3             0x1fffdc	2097116
  r4             0x1	1
  r5             0x1ffffc	2097148
  r6             0x0	0
  r7             0x1fffe0	2097120
  r8             0x0	0
  r9             0x0	0
  r10            0x200100	2097408
  r11            0x1fffe0	2097120
  r12            0x0	0
  sp             0x1fffdc	2097116
  lr             0x81cf	33231
  pc             0x81ae	33198
  fps            0x0	0
  cpsr           0x20000033	536870963
  (gdb) p/x $r7
  $1 = 0x1fffe0
  (gdb) p/x $r11
  $2 = 0x0
  (gdb) quit
  The program is running.  Exit anyway? (y or n) y

Notice in the above that "info reg" prints 0x1fffe0 for the value of
r11, while it actually has a value of 0x0.

The culprit appears to be read_relative_register_raw_bytes_for_frame(),
which is:

  /* FIXME: This function increases the confusion between FP_REGNUM
     and the virtual/pseudo-frame pointer.  */
  
  static int
  read_relative_register_raw_bytes_for_frame (int regnum,
  					    char *myaddr,
  					    struct frame_info *frame)
  {
    int optim;
    if (regnum == FP_REGNUM && frame)
      {
        /* Put it back in target format. */
        store_address (myaddr, REGISTER_RAW_SIZE (FP_REGNUM),
  		     (LONGEST) FRAME_FP (frame));
  
        return 0;
      }
    get_saved_register (myaddr, &optim, (CORE_ADDR *) NULL, frame,
  		      regnum, (enum lval_type *) NULL);
  
    if (register_cached (regnum) < 0)
      return 1;			/* register value not available */
  
    return optim;
  }

Getting rid of the section of code that checks for FP_REGNUM:

    if (regnum == FP_REGNUM && frame)
      {
        /* Put it back in target format. */
        store_address (myaddr, REGISTER_RAW_SIZE (FP_REGNUM),
  		     (LONGEST) FRAME_FP (frame));
  
        return 0;
      }

gets rid of the problem:

  $ ./gdb -nw -nx bug
  GNU gdb 2002-01-22-cvs
  Copyright 2002 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you are
  welcome to change it and/or distribute copies of it under certain conditions.
  Type "show copying" to see the conditions.
  There is absolutely no warranty for GDB.  Type "show warranty" for details.
  This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf"...
  (gdb) tar sim
  Connected to the simulator.
  (gdb) load
  Loading section .init, size 0x14 vma 0x8000
  Loading section .text, size 0x1570 vma 0x8014
  Loading section .fini, size 0x10 vma 0x9584
  Loading section .rodata, size 0x8 vma 0x9594
  Loading section .data, size 0x84c vma 0x969c
  Loading section .eh_frame, size 0x4 vma 0x9ee8
  Loading section .ctors, size 0x8 vma 0x9eec
  Loading section .dtors, size 0x8 vma 0x9ef4
  Loading section .jcr, size 0x4 vma 0x9efc
  Start address 0x80cc
  Transfer rate: 61440 bits in <1 sec.
  (gdb) br callee2
  Breakpoint 1 at 0x81ae: file bug.c, line 6.
  (gdb) run
  Starting program: /build/sourceware/gdb/H-i686-pc-linux-gnu/T-arm-elf/gdb/bug 
  
  Breakpoint 1, callee2 (n=1) at bug.c:6
  6	  return 0;
  (gdb) info reg
  r0             0x1	1
  r1             0x1ffffc	2097148
  r2             0x1fffe8	2097128
  r3             0x1fffdc	2097116
  r4             0x1	1
  r5             0x1ffffc	2097148
  r6             0x0	0
  r7             0x1fffe0	2097120
  r8             0x0	0
  r9             0x0	0
  r10            0x200100	2097408
  r11            0x0	0
  r12            0x0	0
  sp             0x1fffdc	2097116
  lr             0x81cf	33231
  pc             0x81ae	33198
  fps            0x0	0
  cpsr           0x20000033	536870963
  (gdb) p/x $r7
  $1 = 0x1fffe0
  (gdb) p/x $r11
  $2 = 0x0
  (gdb) quit
  The program is running.  Exit anyway? (y or n) y
  $ exit
  
Notice now that "info reg" correctly prints 0x0 for r11.

Any comments on the best way to fix this?  I have no idea what the
motivation was to treat the frame pointer as a special case when block
printing the registers.

-Fred

Re: [RFC] "info registers" is misleading

[Michael Snyder]

Fred Fish wrote:
> 
> I had always thought that "info registers" is supposed to tell you
> the actual register contents, and is simply a convenient way to see
> all the registers with one command.  I.E. it is equivalent to
> doing something like:
> 
>         (gdb) p/x $r0
>         (gdb) p/x $r1
>         ...
> 
> While chasing a bug in some THUMB code related to the stack not being
> restored correctly when using the "return xxx" command, I stumbled
> over a case where "info registers" prints the value of r11 differently
> than "p/x $r11" does.
> 
>   Script started on Mon Jan 21 23:33:14 2002
> 
>   $ cat bug.c
>   #include <stdio.h>
> 
>   int
>   callee2 (int n)
>   {
>     return 0;
>   }
> 
>   int
>   callee1 (void)
>   {
>     int n = 1;
>     n = callee2 (n);
>     return n;
>   }
> 
>   int main ()
>   {
>     callee1 ();
>   }
> 
>   $ arm-elf-gcc -mthumb -g -o bug bug.c
> 
>   $ ./gdb-orig -nw -nx bug
>   GNU gdb 2002-01-22-cvs
>   Copyright 2002 Free Software Foundation, Inc.
>   GDB is free software, covered by the GNU General Public License, and you are
>   welcome to change it and/or distribute copies of it under certain conditions.
>   Type "show copying" to see the conditions.
>   There is absolutely no warranty for GDB.  Type "show warranty" for details.
>   This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf"...
>   (gdb) tar sim
>   Connected to the simulator.
>   (gdb) load
>   Loading section .init, size 0x14 vma 0x8000
>   Loading section .text, size 0x1570 vma 0x8014
>   Loading section .fini, size 0x10 vma 0x9584
>   Loading section .rodata, size 0x8 vma 0x9594
>   Loading section .data, size 0x84c vma 0x969c
>   Loading section .eh_frame, size 0x4 vma 0x9ee8
>   Loading section .ctors, size 0x8 vma 0x9eec
>   Loading section .dtors, size 0x8 vma 0x9ef4
>   Loading section .jcr, size 0x4 vma 0x9efc
>   Start address 0x80cc
>   Transfer rate: 61440 bits in <1 sec.
>   (gdb) br callee2
>   Breakpoint 1 at 0x81ae: file bug.c, line 6.
>   (gdb) run
>   Starting program: /build/sourceware/gdb/H-i686-pc-linux-gnu/T-arm-elf/gdb/bug
> 
>   Breakpoint 1, callee2 (n=1) at bug.c:6
>   6       return 0;
>   (gdb) info reg
>   r0             0x1    1
>   r1             0x1ffffc       2097148
>   r2             0x1fffe8       2097128
>   r3             0x1fffdc       2097116
>   r4             0x1    1
>   r5             0x1ffffc       2097148
>   r6             0x0    0
>   r7             0x1fffe0       2097120
>   r8             0x0    0
>   r9             0x0    0
>   r10            0x200100       2097408
>   r11            0x1fffe0       2097120
>   r12            0x0    0
>   sp             0x1fffdc       2097116
>   lr             0x81cf 33231
>   pc             0x81ae 33198
>   fps            0x0    0
>   cpsr           0x20000033     536870963
>   (gdb) p/x $r7
>   $1 = 0x1fffe0
>   (gdb) p/x $r11
>   $2 = 0x0
>   (gdb) quit
>   The program is running.  Exit anyway? (y or n) y
> 
> Notice in the above that "info reg" prints 0x1fffe0 for the value of
> r11, while it actually has a value of 0x0.
> 
> The culprit appears to be read_relative_register_raw_bytes_for_frame(),
> which is:
> 
>   /* FIXME: This function increases the confusion between FP_REGNUM
>      and the virtual/pseudo-frame pointer.  */
> 
>   static int
>   read_relative_register_raw_bytes_for_frame (int regnum,
>                                             char *myaddr,
>                                             struct frame_info *frame)
>   {
>     int optim;
>     if (regnum == FP_REGNUM && frame)
>       {
>         /* Put it back in target format. */
>         store_address (myaddr, REGISTER_RAW_SIZE (FP_REGNUM),
>                      (LONGEST) FRAME_FP (frame));
> 
>         return 0;
>       }
>     get_saved_register (myaddr, &optim, (CORE_ADDR *) NULL, frame,
>                       regnum, (enum lval_type *) NULL);
> 
>     if (register_cached (regnum) < 0)
>       return 1;                 /* register value not available */
> 
>     return optim;
>   }
> 
> Getting rid of the section of code that checks for FP_REGNUM:
> 
>     if (regnum == FP_REGNUM && frame)
>       {
>         /* Put it back in target format. */
>         store_address (myaddr, REGISTER_RAW_SIZE (FP_REGNUM),
>                      (LONGEST) FRAME_FP (frame));
> 
>         return 0;
>       }
> 
> gets rid of the problem:
> 
>   $ ./gdb -nw -nx bug
>   GNU gdb 2002-01-22-cvs
>   Copyright 2002 Free Software Foundation, Inc.
>   GDB is free software, covered by the GNU General Public License, and you are
>   welcome to change it and/or distribute copies of it under certain conditions.
>   Type "show copying" to see the conditions.
>   There is absolutely no warranty for GDB.  Type "show warranty" for details.
>   This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf"...
>   (gdb) tar sim
>   Connected to the simulator.
>   (gdb) load
>   Loading section .init, size 0x14 vma 0x8000
>   Loading section .text, size 0x1570 vma 0x8014
>   Loading section .fini, size 0x10 vma 0x9584
>   Loading section .rodata, size 0x8 vma 0x9594
>   Loading section .data, size 0x84c vma 0x969c
>   Loading section .eh_frame, size 0x4 vma 0x9ee8
>   Loading section .ctors, size 0x8 vma 0x9eec
>   Loading section .dtors, size 0x8 vma 0x9ef4
>   Loading section .jcr, size 0x4 vma 0x9efc
>   Start address 0x80cc
>   Transfer rate: 61440 bits in <1 sec.
>   (gdb) br callee2
>   Breakpoint 1 at 0x81ae: file bug.c, line 6.
>   (gdb) run
>   Starting program: /build/sourceware/gdb/H-i686-pc-linux-gnu/T-arm-elf/gdb/bug
> 
>   Breakpoint 1, callee2 (n=1) at bug.c:6
>   6       return 0;
>   (gdb) info reg
>   r0             0x1    1
>   r1             0x1ffffc       2097148
>   r2             0x1fffe8       2097128
>   r3             0x1fffdc       2097116
>   r4             0x1    1
>   r5             0x1ffffc       2097148
>   r6             0x0    0
>   r7             0x1fffe0       2097120
>   r8             0x0    0
>   r9             0x0    0
>   r10            0x200100       2097408
>   r11            0x0    0
>   r12            0x0    0
>   sp             0x1fffdc       2097116
>   lr             0x81cf 33231
>   pc             0x81ae 33198
>   fps            0x0    0
>   cpsr           0x20000033     536870963
>   (gdb) p/x $r7
>   $1 = 0x1fffe0
>   (gdb) p/x $r11
>   $2 = 0x0
>   (gdb) quit
>   The program is running.  Exit anyway? (y or n) y
>   $ exit
> 
> Notice now that "info reg" correctly prints 0x0 for r11.
> 
> Any comments on the best way to fix this?  I have no idea what the
> motivation was to treat the frame pointer as a special case when block
> printing the registers.

This is an old old issue.  The frame pointer register
is special.  Info registers does not show the actual
value of the fp register -- it shows the virtual frame pointer
(the address of the function's stack frame).  Usually
it's the same value -- unles you're in a frameless function
(ie. one that does not use the frame pointer register).

Now that we have pseudo-registers, we've talked about 
adding a pseudo-frame-pointer register and using it for
FP_REGNUM, so that the "real" frame pointer register can
always display its real value.

Re: [RFC] "info registers" is misleading

[Eli Zaretskii]

> Date: Mon, 21 Jan 2002 23:08:36 -0800
> From: Michael Snyder <msnyder@redhat.com>
> 
> This is an old old issue.  The frame pointer register
> is special.  Info registers does not show the actual
> value of the fp register -- it shows the virtual frame pointer
> (the address of the function's stack frame).  Usually
> it's the same value -- unles you're in a frameless function
> (ie. one that does not use the frame pointer register).

Shouldn't we document this?  I can write up the change, if you tell
me that the above description is all that there is to it.

TIA

Re: [RFC] "info registers" is misleading

[Richard Earnshaw]

> > Date: Mon, 21 Jan 2002 23:08:36 -0800
> > From: Michael Snyder <msnyder@redhat.com>
> > 
> > This is an old old issue.  The frame pointer register
> > is special.  Info registers does not show the actual
> > value of the fp register -- it shows the virtual frame pointer
> > (the address of the function's stack frame).  Usually
> > it's the same value -- unles you're in a frameless function
> > (ie. one that does not use the frame pointer register).
> 
> Shouldn't we document this?  I can write up the change, if you tell
> me that the above description is all that there is to it.

No, we should fix it.  Lying about what is in a machine register is just 
misleading.

R.

Re: [RFC] "info registers" is misleading

[Andrew Cagney]

> Date: Mon, 21 Jan 2002 23:08:36 -0800
>> From: Michael Snyder <msnyder@redhat.com>
>> 
>> This is an old old issue.  The frame pointer register
>> is special.  Info registers does not show the actual
>> value of the fp register -- it shows the virtual frame pointer
>> (the address of the function's stack frame).  Usually
>> it's the same value -- unles you're in a frameless function
>> (ie. one that does not use the frame pointer register).
> 
> 
> Shouldn't we document this?  I can write up the change, if you tell
> me that the above description is all that there is to it.


It is :-) Per gdb/251, the doco gets it right!  It is GDB that is 
getting it wrong :-(

Andrew

Re: [RFC] "info registers" is misleading

[Richard Earnshaw]

msnyder@redhat.com said:
> This is an old old issue.  The frame pointer register is special.
> Info registers does not show the actual value of the fp register -- it
> shows the virtual frame pointer (the address of the function's stack
> frame).  Usually it's the same value -- unles you're in a frameless
> function (ie. one that does not use the frame pointer register).

> Now that we have pseudo-registers, we've talked about  adding a
> pseudo-frame-pointer register and using it for FP_REGNUM, so that the
> "real" frame pointer register can always display its real value. 

Indeed.  It isn't even confined to Thumb code.  If you have ARM code 
compiled with -fomit-frame-pointer, then gdb will confuse the 
stack-pointer and frame-pointer registers.  Very hard to work out what is 
happening, especially if you want to force a register.

If we add extra gloop to "info registers" for printing out the 
pseudo-frame-pointer register, then please don't call it "fp" (or at least 
allow a target to provide its own name): "fp" is a well-known alias on the 
arm (defined by the APCS) for r11.  Users should be able to use fp as the 
ARM register r11 and will get confused if it represents anything else.

R.

Re: [RFC] "info registers" is misleading

[Michael Snyder]

Richard Earnshaw wrote:
> 
> msnyder@redhat.com said:
> > This is an old old issue.  The frame pointer register is special.
> > Info registers does not show the actual value of the fp register -- it
> > shows the virtual frame pointer (the address of the function's stack
> > frame).  Usually it's the same value -- unles you're in a frameless
> > function (ie. one that does not use the frame pointer register).
> 
> > Now that we have pseudo-registers, we've talked about  adding a
> > pseudo-frame-pointer register and using it for FP_REGNUM, so that the
> > "real" frame pointer register can always display its real value.
> 
> Indeed.  It isn't even confined to Thumb code.  

It isn't even confined to ARM code.  It's true for all architectures.

Re: [RFC] "info registers" is misleading

[Andrew Cagney]

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

Fred,

Have a look through gdb/521.

http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=251&return_url=http%3A%2F%2Fsources.redhat.com%2Fcgi-bin%2Fgnatsweb.pl%3Fdatabase%3Dgdb%26category%3Dall%26severity%3Dall%26priority%3Dall%26responsible%3Dall%26submitter_id%3Dall%26state%3Dall%26ignoreclosed%3DIgnore%2520Closed%26class%3Dall%26synopsis%3D%26multitext%3D%26columns%3Dcategory%26columns%3Dstate%26columns%3Dresponsible%26columns%3Dsynopsis%26displaydate%3DDisplay%2520Current%2520Date%26cmd%3Dsubmit%2520query%26sortby%3DResponsible%26.cgifields%3Dcolumns%26.cgifields%3Doriginatedbyme%26.cgifields%3Ddisplaydate%26.cgifields%3Dignoreclosed

(I don't know of the attached link will work or not)
Andrew

[-- Attachment #2: View PR 251 - gnatsweb --]
[-- Type: text/html, Size: 9931 bytes --]