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

Maciej W. Rozycki
Tue Sep 9 17:57:00 GMT 2014


> >  BTW, I've had some FR=1 stuff ongoing too, though regrettably stalled 
> > recently, see:
> > 
> >
> >
> > 
> > -- 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.

 Hmm, I think this stuff would be best made incrementally anyway.  We have 
a bug to fix here and a new feature.  I'd rather kept changes to address 
them separate.

> 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).

 One issue here is FR can now be changed at the run time, with the UFR 
feature, so the register set presented will have to change dynamically, 
according to that setting even for Linux targets.  I have addressed this 
to some extent for bare iron, but with Linux that means `gdbserver' 
changes as well (as you noted).  I think raw registers should reflect 
precisely the state of hardware and all the mapping based on FR should be 
done for cooked registers only.

> * expose CP0 Config5 as a new register (contains the FRE bit, only
> really relevant when FR=1)

 I smell ABI problems here (think core files and maybe signal frames), 
what is this bit for and why was it added to CP0.Config5 rather than 
CP0.Status?  Is this stuff publicly documented anywhere? -- I don't see it 
in documentation I have handy, not even for rev. 6 of the architecture, 
let alone 5.

> * (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).

 Hmm, offhand I think it would be cleaner done the other way round -- 
expose raw 128-bit or 256-bit MSA registers as applicable and let the 
cooked layer map parts to legacy FP or MSA registers as appropriate.  For 
non-MSA cores keep exposing FP registers as usually.  Do you have a 
specific reason why you did it like you did?

> 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

 That doesn't matter I believe, the description has to be interpreted as a 
whole by GDB anyway.  Registers that don't have a special interpretation 
in GDB will simply be passed through and available by their names in the 
usual contexts.  That is at least how this stuff is meant to be working 
I'm told.

 Shouldn't e.g. mips-linux have a variant with CP0.Config5 too?

 Note that inevitably you'll be able to change FR from GDB now too, just 
by poking at it, e.g.:

(gdb) set $sr ^= 1 << 26

The ptrace(2) code in the kernel needs to recognise CP0.Config5.UFR being 
set and allow r/w access to CP0.Status.FR with PTRACE_POKEUSER or 
PTRACE_SETREGS, just as with the CTC1 moves to CP1.UFR and CP1.UNFR, and 
in response to that you need to switch the target description to the new 
register layout instantaneously.  Same with e.g. single-stepping over 
these instructions.

> 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.

 IMO you don't have to be concerned with stone-age versions of GDB, our 
intent is to support old remote stubs with current GDB (stubs are not 
always easy to upgrade and sometimes not really possible, if built into 
firmware for example), but not the other way round.  If you've got modern 
`gdbserver', then just use GDB you've built along it.

> 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.

 No, as far as I'm concerned.

 BTW, while making such changes you need to verify the correct operation 
of native GDB too.


More information about the Gdb mailing list