On 2/14/21 6:58 PM, Philippe Mathieu-Daudé wrote:
> The R5900 CPU was removed some time ago (frankly I don't remember
> why). This series add it back, but to prove it works, we also add
> testing at the end.
>
> The main motivation is to have MIPS R5900 coverage, but to be able
> to run real world r5900 binaries, I had to implement more opcodes.
>
> 42 patches are a lot, but 3 are already queued in linux-user-for-6.0,
> and the 11 last ones are pure testing. I suppose in next versions
> I'll split the testing patches, but to show the final objective I
> included them in here.
>
> I tagged it RFC because some parts because:
>
> - We'd rather not add yet another target, but we need the
> ILP32-on-64bit ABI (o32 64-bit)
>
> - RDHWR glibc kludge for user-mode
>
> - Avocado patches are only here to show the final test.
> They are useful for my set of tests, but not meant to
> be merged in mainstream.
>
> - gitlab jobs are only here to show the tests work.
> If the target is ever accepted, it would go in an already
> existing job.
>
> I'm OK to maintain 64-bit o32 and the testing out of tree, but the
> TCG opcodes are worthwhile review for mainstream.
I forgot to mention, to debug this target with gdb (the various
multimedia opcodes are not recognized by QEMU disas).
I start QEMU listening for GDB with:
$ qemu-r5900o32el -g 1234 ...
Then start Debian's gdb-multiarch via Docker:
$ docker run -it --rm -v /tmp:/tmp -u $UID --network=host \
registry.gitlab.com/qemu-project/qemu/qemu/debian10 \
gdb-multiarch -q \
--ex 'set architecture mips:5900' --ex 'set endian little'
The target architecture is assumed to be mips:5900
The target is assumed to be little endian
(gdb)
Connect to QEMU on host:
(gdb) target remote 172.17.0.1:1234
Opcodes are displayed properly:
(gdb) x/20i 0x0002553c
0x2553c: pcpyld a1,a1,a1
0x25540: li a2,255
0x25544: andi t1,a0,0x7
0x25548: beqz t1,0x255fc
0x2554c: andi t1,a0,0xf
0x25550: lw t0,0(a0)
0x25554: addiu a0,a0,4
0x25558: pceqb t2,t0,zero
0x2555c: pceqb t3,t0,a1
0x25560: or t4,t3,t2
0x25564: pextlw t4,zero,t4
0x25568: beqz t4,0x255fc
One limitation is we can not access the upper halves of
the 128-bit general purpose registers :(
[Maybe we can but I don't know how...]
Regards,
Phil.
