From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1423 invoked by alias); 5 May 2014 09:50:39 -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 1405 invoked by uid 89); 5 May 2014 09:50:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: glazunov.sibelius.xs4all.nl Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 05 May 2014 09:50:38 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3) with ESMTP id s459oUlf025315; Mon, 5 May 2014 11:50:30 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3/Submit) id s459oUZt005380; Mon, 5 May 2014 11:50:30 +0200 (CEST) Date: Mon, 05 May 2014 09:50:00 -0000 Message-Id: <201405050950.s459oUZt005380@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: arnez@linux.vnet.ibm.com CC: gdb-patches@sourceware.org In-reply-to: <878uqp4wa6.fsf@br87z6lw.de.ibm.com> (message from Andreas Arnez on Mon, 28 Apr 2014 11:51:13 +0200) Subject: Re: [RFC 09/23] SPARC: Rename register maps from "*regset" to "*regmap" References: <87eh0h6bkq.fsf@br87z6lw.de.ibm.com> <878uqp4wa6.fsf@br87z6lw.de.ibm.com> X-SW-Source: 2014-05/txt/msg00038.txt.bz2 > From: Andreas Arnez > Date: Mon, 28 Apr 2014 11:51:13 +0200 > > As a preparation for the next patch in this series, this patch clears > the naming confusion about "regset" versus "sparc*regset". The latter > was used to represent the *map* of a register set, not the register > set itself, and is thus renamed accordingly. > > The following identifiers are renamed: > > sparc32_bsd_fpregset => sparc32_bsd_fpregmap > sparc32_linux_core_gregset => sparc32_linux_core_gregmap > sparc32_sol2_fpregset => sparc32_sol2_fpregmap > sparc32_sol2_gregset => sparc32_sol2_gregmap > sparc32_sunos4_fpregset => sparc32_sunos4_fpregmap > sparc32_sunos4_gregset => sparc32_sunos4_gregmap > sparc32nbsd_gregset => sparc32nbsd_gregmap > sparc64_bsd_fpregset => sparc64_bsd_fpregmap > sparc64_linux_core_gregset => sparc64_linux_core_gregmap > sparc64_linux_ptrace_gregset => sparc64_linux_ptrace_gregmap > sparc64_sol2_fpregset => sparc64_sol2_fpregmap > sparc64_sol2_gregset => sparc64_sol2_gregmap > sparc64fbsd_gregset => sparc64fbsd_gregmap > sparc64nbsd_gregset => sparc64nbsd_gregmap > sparc64obsd_core_gregset => sparc64obsd_core_gregmap > sparc64obsd_gregset => sparc64obsd_gregmap > sparc_fpregset => sparc_fpregmap > sparc_gregset => sparc_gregmap > sparc_sol2_fpregset => sparc_sol2_fpregmap > sparc_sol2_gregset => sparc_sol2_gregmap Sounds reasonable to me; didn't spot any problems.