From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2285 invoked by alias); 30 Dec 2014 01:15:57 -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 2264 invoked by uid 89); 30 Dec 2014 01:15:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 30 Dec 2014 01:15:49 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1Y5lPV-0000ci-39 from Maciej_Rozycki@mentor.com ; Mon, 29 Dec 2014 17:15:45 -0800 Received: from localhost (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 30 Dec 2014 01:15:43 +0000 Date: Tue, 30 Dec 2014 01:15:00 -0000 From: "Maciej W. Rozycki" To: Pedro Alves CC: Yao Qi , Subject: Re: [PATCH] MIPS: Handle the DSP registers for bare metal In-Reply-To: <5494098B.7080002@redhat.com> Message-ID: References: <1418909149-29929-1-git-send-email-yao@codesourcery.com> <54930ED2.1080806@redhat.com> <87r3vwqooq.fsf@codesourcery.com> <5494098B.7080002@redhat.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2014-12/txt/msg00672.txt.bz2 On Fri, 19 Dec 2014, Pedro Alves wrote: > >> Took me a bit to grok this, but this is adding slack for ACXn, right? > > > > Sorry, what do you mean by "slack" here? Is it "gap" or something else? > > Yes, "gap". > > > The offsets of DSP registers are different on linux and bare metal, so > > this patch gives the correct offset or layout to them. > > The proper solution for this issue is to decouple GDB's internal > register numbers from the target's g/G packet layout, which is exactly > what happens when you have a description -- GDB uses the offsets found > in the target description. And you're touching code that is parsing a > description, so the real issue should be in the target description. I'm not sure offhand whether the piece of patch proposed you refer to here is correct or not, but the overall scope of this and the other patch Yao has mentioned yet outstanding is support for legacy bare-metal RSP stubs that have no notion of target descriptions and may even predate GDB's support for these descriptions, and yet they want to make all processor registers available for inspection and modification by GDB. This code comes from MIPS UK and dates back to early 2000s and I think it would be good having it upstream so that standard GDB can talk to these stubs. The fixed layout of the g/G packet and corresponding p/P packet offsets have been set by the bare-metal SDE toolchain years ago. The layout has one significant shortcoming in that it does not support 64-bit FPRs (CP0.Status.FR=1 mode) in the 32-bit mode (o32 ABI or plain 32-bit processors) as there is no room provided for the high 32-bit parts of these registers. > >> But it seems like nothing in GDB knows about those ACX registers. I > >> guess I'm being dense, but why is this patch needed then? They should still > >> be accessible to the user even without this change, right? Assuming the > >> description is including them. The gaps for the extra ACX registers have never been actually filled, no processor has ever existed that supported them. These were provided for processors that support the SmartMIPS and the DSP ASE both at a time, but no such processor has ever been made after all. The only place such a configuration could potentially be enabled right now in a straightforward manner is QEMU, but the emulator does not currently support exchanging the extra registers defined by this change (there is some support for poking at some of these registers via the `monitor' command though; the usual limitations apply, e.g. it can't be used in expressions). Some background information: ACX is the ACcumulator eXtension register defined by the SmartMIPS ASE and holds the highest part of a number whose lower parts are held in the traditional MIPS HI/LO MDU unit's register pair aka MDU accumulator (ACX extends the HI/LO register pair). The DSP ASE defines 3 extra HI/LO register pairs for a total of 4 accumulators. A processor with both ASEs combined would therefore require 3 extra ACX registers (for a total of 4) to extend the 3 additional accumulators. Of course the gaps need to be preserved so as to get the offsets of registers placed beyond them right, as stubs will include/expect these gaps in packets exchanged. > > We want the number of these registers are fixed, and these fixed numbers > > will be used in a follow-up patch about dynamic registers discovery > > (which is about reading available config registers and parsing bits in them) > > MIPS architecture defines 50+ subset of optional CP0 registers, so the > > number of variants is too high to make current static register > > description approach useless. > > I think this should be discussed further. Absolutely, having support for target descriptions in bare-metal RSP stubs (and any complementing changes possibly required for GDB), will certainly be a good feature, lifting the problem with 64-bit FPRs on 32-bit targets as a side effect too. However it will not work for older bare-metal stubs that have been out there for 10+ years now (and actually all in existence right now, I believe). Maciej