> > I suggest that for 32-bit kernels you simply reuse the existing snippets
> > from that function and handle ldc1/sdc1 with a pair of lwl/ldr or swl/swr
> > pairs ordered as appropriate for the endianness selected -- that should be
> > fairly easy.
> Hm I still don't understand well enough how to do that. Would I need to get
> aligned memory (a stack automatic variable for example), copy the double word
> there with proper endianness, and then call again ldc1? (similar for sdc1)
No need to copy anything to scratch space, you'd just handle the thing
piecewise in 32-bit chunks, transferring one FPR first, followed with the
other one -- this is exactly what LDC1/SDC1 logically do in the 32-bit
mode anyway. Of course FPR indices are swapped between endiannesses (or
data in memory is swapped -- depending on how you look at it).
> > Also regardless of that, please make sure that your code handles the two
> > possible settings of CP0 Status register's bit FR correctly, as the 32-bit
> > halves of floating-point data are distributed differently across
> > floating-point registers based on this bit's setting (check if an o32 and
> > an n64 or n32 program gets these values right).
> Hm I'm failing to find in the mips-iv.pdf how to check that FR bit, although I
> see it mentioned there. Sorry.
That'll be set in Linux's task status structure somewhere as the
floating-point model is implied by the ABI (FR is clear for o32 and set
for n32/n64) -- no need to poke at hardware. Have a look at FP context
switching code -- it has to take similar measures. There may be some code
that checks that in the FPU emulator as well.
> > > As Jonas reported, I think that maybe I should rework the patch for it to
> > > emit
> > > sigbus instead of sigill on ldc1,ldc1 for mips32. Do I understand it
> > > right?
> > Have you checked your code against a non-FPU processor (or with the
> > "nofpu" kernel option) too?
> No. Would in that case the processor have the fpu disabled? I understand that
> the code path is called only in a particular case of 'unaligned access'
It may well possibly be, I'm not sure offhand, but unaligned access
emulation just has to work the same for floating-point transfers
regardless of whether the FPU has been enabled or is fully emulated.
This just have to be verified.
The MIPS/Linux user ABI specifies the presence of an FPU unconditionally
and a missing or disabled unit is automatically emulated in software
transparently (except for the performance loss of course).