From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13023 invoked by alias); 10 Dec 2010 14:46:06 -0000 Received: (qmail 13007 invoked by uid 22791); 10 Dec 2010 14:46:05 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 10 Dec 2010 14:46:00 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id oBAEhHCi000982; Fri, 10 Dec 2010 15:43:17 +0100 (CET) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id oBAEhFiT023638; Fri, 10 Dec 2010 15:43:15 +0100 (CET) Date: Fri, 10 Dec 2010 14:46:00 -0000 Message-Id: <201012101443.oBAEhFiT023638@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: yao@codesourcery.com CC: gdb-patches@sourceware.org In-reply-to: <4D022D1A.7030701@codesourcery.com> (message from Yao Qi on Fri, 10 Dec 2010 21:37:30 +0800) Subject: Re: [patch, arm] Consistent display of registers in corefile References: <4D022D1A.7030701@codesourcery.com> 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/msg00137.txt.bz2 > Date: Fri, 10 Dec 2010 21:37:30 +0800 > From: Yao Qi > > 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? I would suspect that the proper thing to do would be to align the tdesc with the code instead of the other way around. The arm-core.xml file seems to underspecify things by omitting the type=xxx clause on many registers. Whoever wrote arm_register_type() at least had to make a conscious decision about the signedness of the type used for the general purpose registers.