Re: [PATCH v2] MIPS: Add basic R5900 support

["Maciej W. Rozycki" <macro@mips.com>]

Hi Fredrik,

> Debian-based Black Rhino libc.so.6 declares "ELF 32-bit LSB MIPS-III
> version 1" but functions such as strcmp contain both 64-bit and multimedia
> instructions (presumably hand coded in assembly for the R5900):
> 
> 	6005ea90 <strcmp>:
> 	...
> 	6005eb50:	78880000 	lq	t0,0(a0)
> 	6005eb54:	710043a9 	pcpyud	t0,t0,zero
> 	6005eb58:	1000000c 	b	6005eb8c <strcmp+0xfc>
> 	6005eb5c:	71204ba9 	pcpyud	t1,t1,zero
> 	6005eb60:	dc880000 	ld	t0,0(a0)
> 	6005eb64:	24840008 	addiu	a0,a0,8
> 	6005eb68:	dca90000 	ld	t1,0(a1)
> 	6005eb6c:	710072a8 	pceqb	t6,t0,zero
> 	6005eb70:	71207aa8 	pceqb	t7,t1,zero
> 	6005eb74:	01cf7025 	or	t6,t6,t7
> 	6005eb78:	71097aa8 	pceqb	t7,t0,t1
> 	...
> 
> Hence corruption and register sign-extension failures. One can also note
> that according to the TX-79 manual, for a 32-bit kernel, several MIPS I
> instruction operations are undefined unless registers are sign-extended.

 That's a standard architectural requirement, not related to the kernel 
being 32-bit or 64-bit.  Overall all 32-bit ALU operations, except for SLL 
and SLLV, mandate that their input operands have been sign-extended from 
bit #31.

 I think you need to find another libc (or the whole userland), as I 
previously suggested.  I don't think we want to enable non-standard 
userland semantics, not as yet at least.  Having code supported like the 
snippet you have quoted above would I believe essentially boil down to 
Linux o64 ABI support, and anyway I think GAS should reject MMI 
instructions in the o32 assembly mode (which is something that was missed 
in R5900 support review).  I'll think on a suitable fix for GAS.

> It is unfortunate that these instructions seem untrappable by the R5900,
> instead silently causing strange behaviour and invalid results.

 Indeed, there's no way to trap with operations that break the 32-bit 
sign-extension requirement.  That's no different though from how the 
64-bit Linux kernel has operated for o32 software since forever; we don't 
clear the CP0.Status.UX bit for o32 tasks, although a discussion has been 
underway about changing it as it breaks indexed addressing (not a concern 
for the R5900, as a MIPS IV+ feature, e.g. LDXC1).  This has complications
though as we'd have to implement a TLB refill handler along with the XTLB 
refill handler, which is already taking space the former requires.

> Still left to explain is why the kernel stumbles on registers during
> initialisation, before user applications are invoked.

 Good luck!

  Maciej