From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14089 invoked by alias); 16 Jul 2014 17:52:03 -0000 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 Received: (qmail 14054 invoked by uid 89); 16 Jul 2014 17:52:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e06smtp15.uk.ibm.com Received: from e06smtp15.uk.ibm.com (HELO e06smtp15.uk.ibm.com) (195.75.94.111) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 16 Jul 2014 17:52:00 +0000 Received: from /spool/local by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 16 Jul 2014 18:51:56 +0100 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 16 Jul 2014 18:51:55 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 9459B2190045 for ; Wed, 16 Jul 2014 18:51:40 +0100 (BST) Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [9.149.37.248]) by b06cxnps3074.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s6GHpss635651590 for ; Wed, 16 Jul 2014 17:51:54 GMT Received: from d06av07.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s6GHpsCn026597 for ; Wed, 16 Jul 2014 13:51:54 -0400 Received: from br87z6lw.de.ibm.com (dyn-9-152-212-196.boeblingen.de.ibm.com [9.152.212.196]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s6GHpriP026593; Wed, 16 Jul 2014 13:51:53 -0400 From: Andreas Arnez To: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, schwab@linux-m68k.org (Andreas Schwab) Subject: Re: [PATCH v2 12/13] M68K Linux: Define regset structures. References: <201407151207.s6FC7Oob018694@d06av02.portsmouth.uk.ibm.com> Date: Wed, 16 Jul 2014 18:01:00 -0000 In-Reply-To: <201407151207.s6FC7Oob018694@d06av02.portsmouth.uk.ibm.com> (Ulrich Weigand's message of "Tue, 15 Jul 2014 14:07:24 +0200 (CEST)") Message-ID: <87pph5chty.fsf@br87z6lw.de.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14071617-0342-0000-0000-000000777DF1 X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00446.txt.bz2 On Tue, Jul 15 2014, Ulrich Weigand wrote: > Andreas Arnez wrote: > >> +static const struct regcache_map_entry m68k_linux_fpregmap[] = >> + { >> + { 8, M68K_FP0_REGNUM }, /* fp0 ... fp7 */ >> + { 1, M68K_FPC_REGNUM }, >> + { 1, M68K_FPS_REGNUM }, >> + { 1, M68K_FPI_REGNUM }, >> + { 0 } >> + }; >> + >> +#define M68K_LINUX_FPREGS_SIZE (27 * 4) > > Hmm. Not sure what happens on m68k_coldfire_flavour, where the GDB > FP registers have builtin_double type (i.e. 8 instead of 12 bytes). > On the other hand, the current m68klinux-nat.c supply_fpregset > doesn't make any provisions for that case either ... is coldfire > supported on Linux at all? At least in the Linux kernel source, e.g. in arch/m68k/Kconfig.cpu, it looks to be supported. And it seems that the registers are still assigned to 12-byte slots, even if they fit in 8 bytes. So, supply_fpregset may work correctly on ColdFire, but then the new code doesn't. Maybe it helps to add a "register slot size" field to each regmap entry? So we'd write: static const struct regcache_map_entry m68k_linux_fpregmap[] = { { 8, M68K_FP0_REGNUM, 12 }, /* fp0 ... fp7 */ { 1, M68K_FPC_REGNUM, 4 }, { 1, M68K_FPS_REGNUM, 4 }, { 1, M68K_FPI_REGNUM, 4 }, { 0 } }; This approach would also make the offsets and total size more obvious -- in this case 8 * 12 + 3 * 4. On the downside, it doesn't allow re-using the same map for different word sizes. Perhaps we could additionally permit the 'size' field to be zero and then use the register size instead. Thoughts?