From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29660 invoked by alias); 10 Dec 2010 13:37:48 -0000 Received: (qmail 29518 invoked by uid 22791); 10 Dec 2010 13:37:47 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 10 Dec 2010 13:37:42 +0000 Received: (qmail 1508 invoked from network); 10 Dec 2010 13:37:39 -0000 Received: from unknown (HELO ?192.168.0.102?) (yao@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Dec 2010 13:37:39 -0000 Message-ID: <4D022D1A.7030701@codesourcery.com> Date: Fri, 10 Dec 2010 13:37:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: [patch, arm] Consistent display of registers in corefile Content-Type: multipart/mixed; boundary="------------000405020409030104090909" X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-12/txt/msg00134.txt.bz2 This is a multi-part message in MIME format. --------------000405020409030104090909 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-length: 1769 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 ^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 ^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 (齐尧) --------------000405020409030104090909 Content-Type: text/x-patch; name="reg_type.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="reg_type.patch" Content-length: 610 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 --------------000405020409030104090909 Content-Type: text/x-patch; name="arm_fps_group.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arm_fps_group.patch" Content-length: 1418 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); +} + /* 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. */ --------------000405020409030104090909--