bug-gdb
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

'info frame' bogosity printing register save locations


From: Christopher K. Smith
Subject: 'info frame' bogosity printing register save locations
Date: Thu, 11 Jan 2007 07:55:46 -0700 (MST)

Symptom:
  On ia64, 'info frame' produces duplicated and confusing info about
  where local registers are saved

Suggested fix:

diff -ruN gdb-6.5/gdb/stack.c cks-6.5/gdb/stack.c
--- gdb-6.5/gdb/stack.c 2006-03-30 09:37:13.000000000 -0700
+++ cks-6.5/gdb/stack.c 2007-01-09 13:34:09.244955485 -0700
@@ -1049,7 +1049,8 @@
     numregs = NUM_REGS + NUM_PSEUDO_REGS;
     for (i = 0; i < numregs; i++)
       if (i != SP_REGNUM
-         && gdbarch_register_reggroup_p (current_gdbarch, i, all_reggroup))
+         && gdbarch_register_reggroup_p (current_gdbarch, i, all_reggroup)
+         && *gdbarch_register_name (current_gdbarch, i))
        {
          /* Find out the location of the saved register without
              fetching the corresponding value.  */

Example:

  [without fix]

  (gdb) i fra
  Stack level 0, frame at 0x2000000000f18220:
   pc = 0x2000000000472d80 in raise; saved pc 0x2000000000475600
   called by frame at 0x2000000000f18330
   Arglist at 0x2000000000f18220, args: 
   Locals at 0x2000000000f18220, Saved registers:
     at 0x200000000071c478,  at 0x200000000071c480,  at 0x200000000071c488,
     at 0x200000000071c490,  at 0x200000000071c498,  at 0x200000000071c4a0,
     at 0x200000000071c4a8,  at 0x200000000071c4b0,  at 0x200000000071c4b8,
     at 0x200000000071c4c0,  at 0x200000000071c4c8,  at 0x200000000071c4d0,
     at 0x200000000071c4d8,  at 0x200000000071c4e0,  at 0x200000000071c4e8,
     at 0x200000000071c4f0,  at 0x200000000071c4f8,  at 0x200000000071c500,
     at 0x200000000071c508, r32 at 0x200000000071c478,
    r33 at 0x200000000071c480, r34 at 0x200000000071c488,
    r35 at 0x200000000071c490, r36 at 0x200000000071c498,
    r37 at 0x200000000071c4a0, r38 at 0x200000000071c4a8,
    r39 at 0x200000000071c4b0, r40 at 0x200000000071c4b8,
    r41 at 0x200000000071c4c0, r42 at 0x200000000071c4c8,
    r43 at 0x200000000071c4d0, r44 at 0x200000000071c4d8,
    r45 at 0x200000000071c4e0, r46 at 0x200000000071c4e8,
    r47 at 0x200000000071c4f0, r48 at 0x200000000071c4f8,
    r49 at 0x200000000071c500, r50 at 0x200000000071c508

  [with fix]

  (gdb) i frame
  Stack level 0, frame at 0x2000000000f18220:
   pc = 0x2000000000472d80 in raise; saved pc 0x2000000000475600
   called by frame at 0x2000000000f18330
   Arglist at 0x2000000000f18220, args: 
   Locals at 0x2000000000f18220, Saved registers:
    r32 at 0x200000000071c478, r33 at 0x200000000071c480,
    r34 at 0x200000000071c488, r35 at 0x200000000071c490,
    r36 at 0x200000000071c498, r37 at 0x200000000071c4a0,
    r38 at 0x200000000071c4a8, r39 at 0x200000000071c4b0,
    r40 at 0x200000000071c4b8, r41 at 0x200000000071c4c0,
    r42 at 0x200000000071c4c8, r43 at 0x200000000071c4d0,
    r44 at 0x200000000071c4d8, r45 at 0x200000000071c4e0,
    r46 at 0x200000000071c4e8, r47 at 0x200000000071c4f0,
    r48 at 0x200000000071c4f8, r49 at 0x200000000071c500,
    r50 at 0x200000000071c508

Explanation:

  ia64 registers r32-r127 are pseudo registers, but they also
  have ordinary register numbers.

  So the loop in stack.c:frame_info() prints these registers twice,
  once as a register and then again as a pseudo register.

  The cases can be distinguished by the register_names[] of the
  registers.  The real registers have name "", the pseudos have
  names like "r32".

  Alpha and sh also have some registers with name "".  As with ia64,
  if these are ever printed by the loop in frame_info(), the output
  will be nonsensical.

  So the above fix is also correct for other targets that use
  name "" for whatever reason.

  When given an invalid register number, gdbarch_register_name() can
  return NULL (some targets) or raise internal_error (other targets).
  This edit will SEGV if gdbarch_register_number() returns NULL.  That
  may be good enough for something that should never happen; if not,
  checking separately for NULL and "" would avoid the problem.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]