Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Yao Qi <yao@codesourcery.com>
To: gdb-patches@sourceware.org
Subject: [patch, arm] Consistent display of registers in corefile
Date: Fri, 10 Dec 2010 13:37:00 -0000	[thread overview]
Message-ID: <4D022D1A.7030701@codesourcery.com> (raw)

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

GDB trunk has a test failure on ARM,

   FAIL: gdb.base/gcore.exp: corefile restored general registers

In short, this failure is caused by output of 'info registers' before
coredump doesn't match output of 'info registers' when corefole is
loaded again, there are mainly two differences, [1] and [2].

Output before coredump,
r0             0x12008  73736^M
r1             0xbea1f0c0       -1096683328^M
[...]
sp             0xbea1f0a4       0xbea1f0a4^M
lr             0x849b   33947^M
pc             0x83fc   0x83fc <terminal_func+4>^M
cpsr           0x20000030       536870960^M

Output when corefile is loaded,
r0             0x12008  73736^M
r1             0xbea1f0c0       3198283968^M  // <---- [1]
[...]
sp             0xbea1f0a4       0xbea1f0a4^M
lr             0x849b   33947^M
pc             0x83fc   0x83fc <terminal_func+4>^M
fps            0x727a622f       1920623151^M  // <---- [2]
cpsr           0x20000030       536870960^M

The difference [1] is caused by different register types, uint32 vs.
int32.  In tdesc, the type of general register is "int", while in
arm_register_type, it is regarded as builtin_uint32.  This can be fixed
when register type is handled in a consistent way (in reg_type.patch).

The difference [2] is about displaying "fps" in output of "info
registers".  In default_register_reggroup_p, the group of register is
determined by the type of register, which is not very precise.  FPS
should be in float group, but its type is INT.  This can be fixed by
defining ARM's own register_reggroup_p to override
default_register_reggroup_p (in arm_fps_group.patch).

Regression tested with combination of
"\{-mthumb,-marm\}\{-fstack-protector,-fno-stack-protector}\{-march=armv7-a,-march=armv5t\}".

OK for mainline?

-- 
Yao (齐尧)

[-- Attachment #2: reg_type.patch --]
[-- Type: text/x-patch, Size: 610 bytes --]

gdb/
	* arm-tdep.c (arm_register_type): Return builtin_int32 to be
	consistent with types in tdesc.

diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
index 0f38b6b..53d7c1c 100644
--- a/gdb/arm-tdep.c
+++ b/gdb/arm-tdep.c
@@ -2966,7 +2966,8 @@ arm_register_type (struct gdbarch *gdbarch, int regnum)
        an XML description.  */
     return builtin_type (gdbarch)->builtin_int0;
   else
-    return builtin_type (gdbarch)->builtin_uint32;
+    /* To be consistent with types in tdesc.  */
+    return builtin_type (gdbarch)->builtin_int32;
 }
 
 /* Map a DWARF register REGNUM onto the appropriate GDB register

[-- Attachment #3: arm_fps_group.patch --]
[-- Type: text/x-patch, Size: 1418 bytes --]

gdb/
	* arm-tdep.c (arm_register_reggroup_p): New.
	(arm_gdbarch_init): Set arm_register_reggroup_p for hook
	register_reggroup_p.

diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
index 678d44c..21ad876 100644
--- a/gdb/arm-tdep.c
+++ b/gdb/arm-tdep.c
@@ -29,6 +29,7 @@
 #include "gdb_string.h"
 #include "dis-asm.h"		/* For register styles. */
 #include "regcache.h"
+#include "reggroups.h"
 #include "doublest.h"
 #include "value.h"
 #include "arch-utils.h"
@@ -7191,6 +7192,17 @@ arm_elf_osabi_sniffer (bfd *abfd)
   return osabi;
 }
 
+static int
+arm_register_reggroup_p (struct gdbarch *gdbarch, int regnum,
+			  struct reggroup *group)
+{
+  /* FPS register's type is INT, but belongs to float_group.  */
+  if (regnum == ARM_FPS_REGNUM)
+    return (group == float_reggroup);
+  else
+    return default_register_reggroup_p (gdbarch, regnum, group);
+}
+
 \f
 /* Initialize the current architecture based on INFO.  If possible,
    re-use an architecture from ARCHES, which is a list of
@@ -7655,6 +7667,7 @@ arm_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
   set_gdbarch_pc_regnum (gdbarch, ARM_PC_REGNUM);
   set_gdbarch_num_regs (gdbarch, ARM_NUM_REGS);
   set_gdbarch_register_type (gdbarch, arm_register_type);
+  set_gdbarch_register_reggroup_p (gdbarch, arm_register_reggroup_p);
 
   /* This "info float" is FPA-specific.  Use the generic version if we
      do not have FPA.  */

             reply	other threads:[~2010-12-10 13:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-10 13:37 Yao Qi [this message]
2010-12-10 14:46 ` Mark Kettenis
2010-12-10 15:07   ` Yao Qi
2010-12-13  2:57   ` Daniel Jacobowitz
2010-12-13 10:00     ` Yao Qi
2010-12-19 18:24       ` Daniel Jacobowitz
2010-12-20  2:29         ` Yao Qi
2010-12-20  3:09           ` Daniel Jacobowitz
2011-01-13 13:45 ` Yao Qi
2011-01-13 16:04   ` Ulrich Weigand
2011-01-13 16:47     ` Yao Qi
2011-01-14 16:52       ` Ulrich Weigand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D022D1A.7030701@codesourcery.com \
    --to=yao@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox