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

Maciej W. Rozycki
2014-12-30T01:15:57Z

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