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

[Matthew Fortune <Matthew.Fortune@imgtec.com>]

> On Tue, Sep 09, 2014 at 09:39:22PM +0100, James Hogan wrote:
> > > with the UFR
> > > feature, so the register set presented will have to change dynamically,
> > > according to that setting even for Linux targets.
> >
> > I have a feeling that UFR is currently unlikely to be enabled in Linux,
> > due to subtleties with mode switches in multi-threaded processes
> > requiring kernel support. Matthew or Paul (on CC) can probably confirm
> > that.
> 
> Correct, UFR (along with UFE) is currently not enabled by Linux, and I'm
> not aware of any need to deal with the pain involved in enabling it. There
> is a need to switch mode across a whole process, which will need to be met
> in some other way (the prctls in my internal branch, and hopefully the
> same once upstream).

We are quite a long way off topic from the original post but all this is
important for the bulk of James' further patches...

The O32 FR0/FR1 ABI documentation includes basic details of the new FRE
hardware mode and the corresponding new ABI extension FP64A:

https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking#7._Defining_O32_FP64A

A formal PRA document with FRE described is due within a week or so.

It also shows how the program loader is expected to behave:

https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking#10.4._Program_loader

And how mode switching is to be performed:

https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking#10.5.2._Setting_the_FPU_mode

I would like to propose that GDB is not able to change the FR or FRE bits
directly. These bits have to be handled with extreme caution and there is
no plan to support users changing them at arbitrary points either on bare
metal or user-land. The intention is that a program is provided with a
stable environment to run in where every loaded function (and region of
a function) can be executed in the current mode. When adding new code into
a process then a new hardware mode may be required but the change of mode
is performed atomically across all threads in a process. For bare-metal
there is almost no reason anyone will need a mode switch so that can be
disregarded entirely.

I'll reply about register layouts separately although that topic is mostly
subjective.

Thanks,
Matthew