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
