This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]