Hi Maciej,
> > 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.
Sure. I would eventually like to explore solutions to efficiently support
the full register range in applications with both 32- and 64-bit kernels.
> > 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.
It's 72308802 as in "mul s1,s1,s0" which I believe is the DSP enhancement
multiplication with register write in the MIPS32 architecture. The R5900
doesn't have those DSP instructions, as far as I can tell.
For this reason the R5900 patch modifies the __{save,restore}_dsp macros,
mips_dsp_state::dspcontrol, DSP_INIT, sigcontext32::sc_dsp, etc. I've seen
the cpu_has_dsp macro too, but haven't looked at the details of this yet.
Considering the lack of DSP instructions, would you know any commonly
compiled mipsel distribution that could be made compatible with the R5900
in a reasonable manner? I suppose Gentoo has an advantage here, given the
ability to supply R5900 compilation flags.
> Also make sure you have RDHWR instruction emulation in place for CP0
> UserLocal register access.
Right. Debian's BusyBox has 857 of those. Jürgen Urban observed in the
conversation with you in
https://gcc.gnu.org/ml/gcc-patches/2013-01/msg00658.html
that RDHWR has the same encoding as "sq v1,-6085(zero)" for the R5900,
which luckily always gives an alignment exception so that the kernel is
able to emulate RDHWR properly. I haven't verified this though.
Fredrik
