This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Adding MIPS registers (was Re: [PATCH v2] Reset errno before PTRACE_PEEKUSER for MIPS DSP_CONTROL)
- From: James Hogan <james dot hogan at imgtec dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: <gdb at sourceware dot org>
- Date: Tue, 9 Sep 2014 17:46:05 +0100
- Subject: Adding MIPS registers (was Re: [PATCH v2] Reset errno before PTRACE_PEEKUSER for MIPS DSP_CONTROL)
- Authentication-results: sourceware.org; auth=none
- References: <1409608120-23991-1-git-send-email-james dot hogan at imgtec dot com> <alpine dot DEB dot 1 dot 10 dot 1409031340130 dot 27075 at tp dot orcam dot me dot uk> <20140903125111 dot GF12084 at jhogan-linux dot le dot imgtec dot org> <alpine dot DEB dot 1 dot 10 dot 1409031517450 dot 27075 at tp dot orcam dot me dot uk>
Hi Maciej,
On 03/09/14 22:21, Maciej W. Rozycki wrote:
> On Wed, 3 Sep 2014, James Hogan wrote:
>> This is my first GDB patch submitted upstream (although I have a pile of
>> RFC patches for FR=1, FRE=1, MSA support I'm still getting into shape),
>> so I don't have push access yet. Is it easy to arrange?
>
> BTW, I've had some FR=1 stuff ongoing too, though regrettably stalled
> recently, see:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=7518
> http://sourceware.org/ml/gdb-patches/2012-06/msg00201.html
>
> -- based on an old patch from MIPS Technologies that wasn't quite there,
> but still was a good starting point. Bare iron only of course as there
> was no FR=1 Linux ABI up until recently. It will be interesting to see
> how the two pieces compare. Or actually it may make sense if I push my
> piece first, there was just some concern about regcache that remained
> unresolved, so I'll see if I can reintegrate that change against current
> trunk, retest and repost.
Yes, that's what I've based my work on, but with some changes since it
needs to support FRE=1 too.
I've added a number of new MIPS registers, but I'm keen to get guidance
about gdbserver ABI issues. Perhaps you or somebody else could comment.
The main register changes are:
* the MIPS32 fp registers are sometimes extended to 64-bits, at least
when FR=1 (at the moment I've made gdbserver extend to 64-bits whenever
FIR.F64=1, so that the register format cannot change during use).
* expose CP0 Config5 as a new register (contains the FRE bit, only
really relevant when FR=1)
* (separately) expose the rest of the MSA vector registers as new
registers (raw register excludes the low 64-bits which alias the double
FP registers, pseudo register concatenates raw fp/vector register together).
Currently I've done this by adding whole new target descriptions:
mips-fpu64-dsp-linux (mips-dsp-linux with 64-bit fp and config5)
mips-fpu64-linux (mips-linux with 64-bit fp and config5)
mips-msa-linux (64-bit fp registers, config5, vector registers)
mips64-msa-linux
and carefully appending Config5 to the following target descriptions (is
that a valid approach, adding registers to the end?):
mips64-dsp-linux
mips64-linux
With a GDB & target that supports XML I believe all should be well.
However with a MIPS32 remote which supports FR=1 (i.e. when FIR.F64=1),
AFAICT GDB without XML target description support has no (simple) way to
tell whether the remote is actually providing 32-bit or 64-bit fp registers.
So, for MIPS do we care about GDB being built without XML support (at
least for gdbserver)? I.e. creation of whole new target descriptions
that a non-xml gdb won't recognise.
Thanks
James