Hi Fredrik,
> > 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?
You mean for use with MMI instructions? Offhand I think we have two
options:
1. Declaring the lack of support for MMI instructions in o32 software.
2. Switching to using LD/SD in <asm/stackframe.h> and preserving statics
across syscalls with SAVE_STATIC/RESTORE_STATIC at the cost of
performance loss.
I'm open for a better suggestion though. I propose that we start with #1,
as the zero performance cost and zero effort solution.
> > 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.
Getting a core dump and using it to figure out which specific instruction
caused the exception would be interesting. Also make sure you have RDHWR
instruction emulation in place for CP0 UserLocal register access.
> > 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.
Ah, OK then.
Maciej
