Re: [RFC PATCH 00/42] target/mips: Reintroduce the R5900 CPU (with more testing)

[Philippe Mathieu-Daudé]

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.