From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26040 invoked by alias); 25 Jan 2017 16:05:58 -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 26029 invoked by uid 89); 25 Jan 2017 16:05:57 -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_PASS autolearn=ham version=3.3.2 spammy=guest, 25.1.2017, 2512017, Hx-languages-length:1769 X-HELO: aserp1040.oracle.com Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Jan 2017 16:05:47 +0000 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v0PG5h5D002034 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jan 2017 16:05:43 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v0PG5hiU006818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jan 2017 16:05:43 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v0PG5gNZ011092; Wed, 25 Jan 2017 16:05:42 GMT Received: from [10.163.45.69] (/10.163.45.69) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Jan 2017 08:05:42 -0800 Subject: Re: [PATCH] Bug 20936 - provide sparc and sparcv9 target description XML files To: Pedro Alves 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> <9351d864-e939-cc66-97e3-1c768bf78df1@redhat.com> Cc: Yao Qi , gdb-patches@sourceware.org From: Ivo Raisr Message-ID: <9cab8cda-99e8-8921-c999-be0324a133f8@oracle.com> Date: Wed, 25 Jan 2017 16:05:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <9351d864-e939-cc66-97e3-1c768bf78df1@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-01/txt/msg00535.txt.bz2 On 25.1.2017 16:46, Pedro Alves wrote: > (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. Good question. The rationale is target provided registers. Consider a typical Valgrind use case where target (gdbserver stub implemented inside Valgrind) supplies 3 times more raw registers than the architecture normally supports. One set mimics the "normal" registers, the other two sets are shadow copies used internally by Memcheck tool to keep track of defined/undefined bits and their origins. So when gdb'ing ordinary process, you have: - raw registers (one set) - pseudo registers However when gdb'ing Valgrind'ed process over gdb remote protocol with --vgdb-shadow-registers=yes, target provides: - first set of raw registers (describes guest state) - second set of raw registers (describes the first shadow copy) - third set of raw registers (describes the second shadow copy) - pseudo registers (actually provided by gdb) So this means pseudo registers numbering must be flexible. Other targets (such as s390x, aarch64, amd64) do it in similar ways. Kind regards, I.