From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30186 invoked by alias); 18 Feb 2008 20:42:18 -0000 Received: (qmail 30177 invoked by uid 22791); 18 Feb 2008 20:42:18 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate3.de.ibm.com (HELO mtagate3.de.ibm.com) (195.212.29.152) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Feb 2008 20:41:56 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id m1IKfrI0209216 for ; Mon, 18 Feb 2008 20:41:53 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m1IKfrfF2257016 for ; Mon, 18 Feb 2008 21:41:53 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m1IKfruH010532 for ; Mon, 18 Feb 2008 20:41:53 GMT Received: from bbkeks.de.ibm.com (dyn-9-152-248-39.boeblingen.de.ibm.com [9.152.248.39]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m1IKfqlW010526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2008 20:41:53 GMT Message-ID: <47B9ED1B.7070303@de.ibm.com> Date: Mon, 18 Feb 2008 20:42:00 -0000 From: Markus Deuling User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: GDB Patches CC: Ulrich Weigand Subject: [rfc] Replace x86 register macros Content-Type: multipart/mixed; boundary="------------030306090003090007030006" 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: 2008-02/txt/msg00307.txt.bz2 This is a multi-part message in MIME format. --------------030306090003090007030006 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1055 Hi, in some places used by x86/amd64 architecture there is a weird mechanism to get at the number of registers or the registers themselves which make the code hard to read. One example is i386_sse_regnum_p in i386-tdep.c where two macros I387_ST0_REGNUM and I387_NUM_XMM_REGS have to be defined so that other two macros I387_XMM0_REGNUM and I387_MXCSR_REGNUM are valid. What I'd like to do is to unknot this source to make it more readable. For my opinion it is bad practice to define and undef macros per funtion in a source file describing a target. What do you think about this in general and about this patch in special? If this would be a way to go I'd like to commit this patch and come up with a bigger one to handle some more of these. Testsuite on x86 showed no regression. ChangeLog: * i386-tdep.c (i386_sse_regnum_p): Replace I387_XMM0_REGNUM and I387_MXCSR_REGNUM by its expressions. Remove I387_ST0_REGNUM and I387_NUM_XMM_REGS. Regards, Markus -- Markus Deuling GNU Toolchain for Linux on Cell BE deuling@de.ibm.com --------------030306090003090007030006 Content-Type: text/plain; name="diff-i386" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diff-i386" Content-length: 751 diff -urpN src/gdb/i386-tdep.c dev/gdb/i386-tdep.c --- src/gdb/i386-tdep.c 2008-01-27 06:30:37.000000000 +0100 +++ dev/gdb/i386-tdep.c 2008-02-18 21:26:40.000000000 +0100 @@ -96,16 +96,9 @@ i386_sse_regnum_p (struct gdbarch *gdbar { struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); -#define I387_ST0_REGNUM tdep->st0_regnum -#define I387_NUM_XMM_REGS tdep->num_xmm_regs - - if (I387_NUM_XMM_REGS == 0) - return 0; - - return (I387_XMM0_REGNUM <= regnum && regnum < I387_MXCSR_REGNUM); - -#undef I387_ST0_REGNUM -#undef I387_NUM_XMM_REGS + /* True if REGNUM in [st0_regnum + 16, st0_regnum + 16 + num_xmm_regs). */ + return (regnum >= tdep->st0_regnum + 16 + && regnum < tdep->st0_regnum + 16 + tdep->num_xmm_regs); } static int --------------030306090003090007030006--