From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117258 invoked by alias); 25 Jan 2017 15:46: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 115737 invoked by uid 89); 25 Jan 2017 15:46:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=sk:misunde, H*f:sk:2017010 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Jan 2017 15:46:28 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DC9A6C04BD38; Wed, 25 Jan 2017 15:46:27 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0PFkQUj010080; Wed, 25 Jan 2017 10:46:27 -0500 Subject: Re: [PATCH] Bug 20936 - provide sparc and sparcv9 target description XML files To: Ivo Raisr , Yao Qi References: <46200a1e-29f7-8e20-c0b5-3f6f25c82d45@oracle.com> <20161206152616.GC28789@E107787-LIN> <83d4c58d-0834-4fc2-6194-72408510aa8a@oracle.com> <20161212125331.GB25542@E107787-LIN> <082f9ac8-3e46-42cd-198d-91866d83ebb8@oracle.com> <20170105143109.GA21293@E107787-LIN> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <9351d864-e939-cc66-97e3-1c768bf78df1@redhat.com> Date: Wed, 25 Jan 2017 15:46:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-01/txt/msg00533.txt.bz2 (I know I'm quite behind this thread.) On 01/06/2017 03:12 PM, Ivo Raisr wrote: > > ChangeLog entry: > 2017-01-06 Ivo Raisr > > Split real and pseudo registers in preparation for registers provided > by a target. Registers provided by target description can have more real > registers and pseudo registers need to be positioned after them. I don't quite understand this rationale, and I'm wondering if there's a misunderstanding of register numbering somewhere (maybe mine!). What exactly would go wrong if you just added the new registers between the existing raw and pseudo registers? Other ports do that routinely. Thanks, Pedro Alves