Hi Maciej,
> > Unfortunately I haven't found such a switch. There is also a set of 128-bit
> > multimedia instructions to consider (GCC is perhaps unlikely to generate
> > those but assembly code is an option too).
>
> The usual minimal approach is to have compiler intrinsics implemented.
I sometimes make less than minimal programs, or unusual ones, or both. ;)
> Virtually all 64-bit MIPS processors have the CP0.Status.UX bit, which
> the Linux kernel keeps clear for o32 processes (CP0.Status.PX is currently
> unsupported and is kept clear as well), which means that an attempt to use
> any instruction that affects register bits beyond bit #31 will cause a
> Reserved Instruction exception, and in turn SIGILL being sent to the
> program.
Would UX be bit 5 of CP0.Status? That bit is hardwired to naught according
to the TX79 manual (p. 4-16).
> So any crash caused by the lack of handling of the upper bits is a result
> of either a kernel bug or an issue with hardware.
R5900 does not seem to implement UX, SX, KX or PX.
> Hmm, can you verify that no LWU instruction is present in the kernel
> somewhere?
Sure, "mipsel-linux-objdump -d vmlinux | grep lwu" yields nil.
> Can you add a diagnostic consistency check to the context restoration
> code, i.e. all the macros called from RESTORE_ALL (in <asm/stackframe.h>),
> such as a `break 12' (BRK_BUG) instruction if a register value is not
> correctly sign-extended? You can instead use one of the register trap
> instructions (with the same BRK_BUG code), to avoid the need for a branch.
> Make sure you don't clobber registers restored; you may have to use $k0 or
> $k1 in places. This will cause a kernel oops, which can then be examined
> to track down a possible cause.
Given the R5900 patch I believe this can be done somewhat simpler, since
register access macros have been implemented in C (in this way the physical
registers become in some sense separated from the logical registers in the
kernel).
The transition from 128-bit registers to 64-bit registers was easy (in a
32-bit kernel) by changing the LONGD_{L,S} macros in asm.h from quadword
{L,S}Q to doubleword {L,S}D instructions, and changing pt_regs::regs[32]
from r5900_reg_t to unsigned long long. (The patch replaces LONG_* with
three variants: LONGD_*, LONGH_* and LONGI_*. It also forces LD and SD
via a ".set push/.set mips3/.set pop" combination like you outline below.)
The patch has full 64-bit registers accessible in C too, which is why I
propose to do the diagnostic consistency check in C. (Macros truncate to
32 bits everywhere in the kernel except for save/restore.)
> GAS will prevent the use of any 64-bit instructions (which LWU is one of)
> when the o32 ABI has been selected for assembly, however it can be
> temporarily overridden by `.set' pseudo-ops, and also I haven't verified
> if there isn't an issue with `-march=r5900' in GAS.
I'm using a BusyBox binary from the Debian-based Black Rhino distribution,
so I'm not entirely sure how it was compiled, and it might contain 64-bit
instructions that are not caught by the (unavailable) UX bit.
Fredrik
