Hi Maciej,
> BTW I think that when we get to supporting 128-bit registers we want to
> avoid changing the definition of LONG_{L,S} macros, because these are used
> for purposes beyond context access.
>
> Instead I think these macros as well all the ones in <asm/stackframe.h>
> should remain unchanged and the save and restoration of the 64-bit upper
> halves done separately, most likely in `switch_to', which is where all the
> user context registers which like these upper halves are not touched by
> the kernel (and which are not handled lazily by other means) are switched.
Hmm... What about a 32-bit kernel and bits 63:32 sign-extended by kernel
instructions? LONG_{L,S} saves/restores 31:0 using LW/SW thus 63:32 will
be lost in exceptions?
> Can you try a regular 32-bit MIPS Debian distribution instead?
BusyBox at
https://packages.debian.org/stretch/mipsel/busybox-static/download
seemed appropriate but yields "illegal instruction" which I suppose is
interesting in itself. My MIPS toolchain is somewhat limited at the moment
so I will need to get back on this.
> BTW, I have just noticed that DMULT, DMULTU, DDIV and DDIVU instructions
> are not implemented. Which means that a 64-bit kernel will only work if
> compiled with `-march=r5900' and emulation is required for 64-bit user
> programs.
Indeed. In the R5900 patch these instructions are emulated (or simulated as
it is called in the source) in
https://github.com/frno7/linux/blob/1c8247e352d1eb7ae9022a76ecf19f74264534f7/arch/mips/kernel/traps.c
along with LLD, SCD, etc.
Fredrik
