Hi Lluís

quoted

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

quoted

 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.

quoted

quoted

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

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

  Maciej