Adding MIPS registers (was Re: [PATCH v2] Reset errno before PTRACE_PEEKUSER for MIPS DSP_CONTROL)

James Hogan <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.