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