On 19/11/13 11:21, Ralf Baechle wrote:
On Tue, Nov 19, 2013 at 11:07:22AM +0000, Paul Burton wrote:
Does anyone still care about the R2300? I ask because I'm working on
the FP context switching code & noticed that I'm pretty sure the
fpu_save_single & fpu_restore_single macros used only from
r2300_switch.S are broken. They store each 32 bit value at the start
of the location of the 64 bit FP registers context in memory, which I
believe:
1) Won't work for odd indexed FP registers with the FPU emulator,
ptrace or other code which assumes that 32 bit FP data is held in
the even-indexed 64 bit FP register context.
Note that much of that code has changed for 3.13 and the new code may or
may not have inherited this bug.
May I ask which code you mean? Is there some FP work not in mips-for-
linux-next or on the mailing list?
2) On big endian systems the 32 bit values will get saved to the most
significant bits of the 64 bit context which I imagine will cause
yet more problems.
It seems like the only changes to r2300_switch.S for a *long* time have
been to keep it in sync with r4k_switch.S & the CPU is old enough that
all I get when I google for it is information about some hay baler.
In short: does anyone care if I just submit a patch removing the R2300
code instead of blindly attempting to fix it up?
Linux/MIPS is a product of the post-R3000 era - but Maciej (on cc) is doing
his best to keep it alive and going on DECstations, including R2000 and
R3000 based ones. DECstations are little endian and all of them have a
R2010 rsp R3010, that is have hardware floating point.
I myself have an R3000-based workstation, a clone of a MIPS RS3230 (I think)
sitting on my floor and waiting to be reactivated. It's still running
RISC/os.
Ralf
Fair enough, I'll leave the r2300_switch.S & fpu_{save,restore}_single
code alone (apart from changes which will leave the bug as-is).
Thanks,
Paul
