Hi Fredrik,
> > 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.
Umm, has Debian switched to MIPS32 as the base architecture? That would
be unfortunate, they used to support MIPS I or at worst MIPS II (ISTR
voices to switch to the latter). There's still plenty of MIPS III
hardware around so for 32-bit support I would consider MIPS II the common
denominator (the sole difference between MIPS II and MIPS III is 64-bit
support).
In any case you'll have to find a MIPS I or MIPS II distribution, like an
older version of Debian.
The three-argument MUL is a part of the base MIPS32 architecture BTW,
originating from the IDT R4650 and the NEC Vr5500 processors. It has
nothing to do with the DSP ASE (though it may have been claimed originally
to be a DSP enhancement).
> 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.
Given that the R5900 does not expand DSP support anyhow that sounds
suspicious to me.
> 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.
I don't know. According to <https://www.debian.org/ports/mips/>:
"Debian GNU/Linux 8.9 supports the following machines:
* SGI Indy with R4x00 and R5000 CPUs, and Indigo2 with R4400 CPU (IP22).
* SGI O2 with R5000, R5200 and RM7000 CPU (IP32).
* Broadcom BCM91250A (SWARM) evaluation board (big and little-endian).
* MIPS Malta boards (big and little-endian, 32 and 64-bit).
* Loongson 2e and 2f machines, including the Yeelong laptop (little-endian).
* Loongson 3 machines (little-endian).
* Cavium Octeon (big-endian).
In addition to the above machines, it is possible to use Debian on a lot
more machines provided that a non-Debian kernel is used. This is for
example the case of the MIPS Creator Ci20 development board."
so your observation looks like a result of a package compilation bug in
the program which crashed. Among the systems listed above there are many
which only support the MIPS III ISA (R4x00, R4400 and Loongson 2e CPUs) or
the MIPS IV ISA (R5000, R5200, RM7000 CPUs). I see the DECstation port
along with R2000 and R3000 CPU support has been removed, so I gather the
baseline is indeed supposed to be MIPS II.
I haven't used Gentoo, but I'm told you can choose your compilation flags
as you like with it.
> > 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.
That instruction encoding (actually implemented by some MIPS32r2/MIPS64r2
and newer hardware) is used under Linux for Thread Local Storage (TLS)
access. For hardware that does not have it the instruction is emulated in
the Reserved Instruction (RI) exception handler, but obviously not the
Address Error Store (AdES) exception. So code to handle it as a special
case with the R5900 has to be provided among the patches (and included
with the initial series).
Note that `rdhwr $3,$29' is the usual encoding, handled by a fastpath in
arch/mips/kernel/genex.S (see `handle_ri_rdhwr'), however all `rt'
encodings (covered in `simulate_rdhwr' in arch/mips/kernel/traps.c) have
to be handled for completeness. Fortunately RDHWR and SQ both use the
same bits for `rt', and the `-6085(zero)' encoding of the memory reference
makes no sense, so we can safely rely on the AdES exception.
Maciej
