This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC] "info registers" is misleading


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]