From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: Pedro Alves <palves@redhat.com>
Cc: Yao Qi <yao@codesourcery.com>, <gdb-patches@sourceware.org>
Subject: Re: [PATCH] MIPS: Handle the DSP registers for bare metal
Date: Tue, 30 Dec 2014 01:15:00 -0000 [thread overview]
Message-ID: <alpine.DEB.1.10.1412300034430.19155@tp.orcam.me.uk> (raw)
In-Reply-To: <5494098B.7080002@redhat.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
next prev parent reply other threads:[~2014-12-30 1:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-18 13:26 Yao Qi
2014-12-18 17:28 ` Pedro Alves
2014-12-19 3:55 ` Yao Qi
2014-12-19 11:18 ` Pedro Alves
2014-12-19 13:22 ` Yao Qi
2014-12-19 15:07 ` Pedro Alves
2014-12-30 1:15 ` Maciej W. Rozycki [this message]
2014-12-30 10:12 ` Pedro Alves
2014-12-30 12:11 ` Maciej W. Rozycki
2015-01-05 11:40 ` Pedro Alves
2015-01-07 15:11 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.1.10.1412300034430.19155@tp.orcam.me.uk \
--to=macro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=yao@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).