Re: [PATCH] MIPS: Handle the DSP registers for bare metal

["Maciej W. Rozycki" <macro at codesourcery dot com>]

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