Recognise the R5900, which reports itself as MIPS III, as a 64-bit CPU
supporting the n32 ABI. Test that DMULT is emulated in user mode.

This series has been successfully built with the 10 different build
configurations

    {gcc,clang} x -m64 x mips{,64}el-{linux-user,softmmu}
    {gcc,clang} x -m64 x mipsn32el-linux-user

in addition successfully completing the R5900 test suite

    cd tests/tcg/mips/mipsr5900 && make check
    cd tests/tcg/mips/mipsn32r5900 && make check

Fredrik Noring (2):
  linux-user/mips: Support the n32 ABI for the R5900
  tests/tcg/mips: Test user mode DMULT for the R5900

 linux-user/mips64/target_elf.h       |  3 +++
 tests/tcg/mips/mipsn32r5900/Makefile | 25 +++++++++++++++++
 tests/tcg/mips/mipsn32r5900/dmult.c  | 40 ++++++++++++++++++++++++++++
 3 files changed, 68 insertions(+)
 create mode 100644 tests/tcg/mips/mipsn32r5900/Makefile
 create mode 100644 tests/tcg/mips/mipsn32r5900/dmult.c

-- 
2.18.1

On 08/11/2018 19:42, Fredrik Noring wrote:
> Recognise the R5900, which reports itself as MIPS III, as a 64-bit CPU
> supporting the n32 ABI. Test that DMULT is emulated in user mode.

if you have time, o32 & n32 support needs to be reworked.

We have two binaries qemu-mips and qemu-mipsn32 sharing the same ELF
mask/magic.

As n32 identifies a kernel ABI version, we should have only one binary
for qemu-mips and qemu-mipsn32 and the ABI version should be identified
at runtime as it is done for ARM:

  ce4defa062 Arm Linux EABI syscall support.

[I think we can use e_flags for that]

I never did the change because I don't know where to find mipsn32
binaries to test my changes.

Thanks,
Laurent

On Fri, 9 Nov 2018, Laurent Vivier wrote:

> if you have time, o32 & n32 support needs to be reworked.
> 
> We have two binaries qemu-mips and qemu-mipsn32 sharing the same ELF
> mask/magic.
> 
> As n32 identifies a kernel ABI version, we should have only one binary
> for qemu-mips and qemu-mipsn32 and the ABI version should be identified
> at runtime as it is done for ARM:
> 
>   ce4defa062 Arm Linux EABI syscall support.

 Are you sure?  So is the ARM ABI handled with ce4defa062 64-bit?

 The o32 ABI is 32-bit (32-bit GPR width) while n32 is 64-bit (64-bit GPR 
width).  The correspondence between the i386 ABI and the x86-64 x32 ABI is 
analogous to these two ABIs.

 How are these x86 ABIs handled WRT the user emulation mode; are they 
analogous to the ARM ABIs you've mentioned?

> [I think we can use e_flags for that]

 The EF_MIPS_ABI2 `e_flags' bit denotes the n32 ABI.  The container format 
is ELF32 obviously, because addressing is 32-bit with n32.

> I never did the change because I don't know where to find mipsn32
> binaries to test my changes.

 I believe MIPS64 Debian is all n32.

  Maciej

On 09/11/2018 15:14, Maciej W. Rozycki wrote:
> On Fri, 9 Nov 2018, Laurent Vivier wrote:
> 
>> if you have time, o32 & n32 support needs to be reworked.
>>
>> We have two binaries qemu-mips and qemu-mipsn32 sharing the same ELF
>> mask/magic.
>>
>> As n32 identifies a kernel ABI version, we should have only one binary
>> for qemu-mips and qemu-mipsn32 and the ABI version should be identified
>> at runtime as it is done for ARM:
>>
>>   ce4defa062 Arm Linux EABI syscall support.
> 
>  Are you sure?  So is the ARM ABI handled with ce4defa062 64-bit?

I'm sure of nothing. It's why it's better if someone involved in mips
development has an opinion on it :)

>  The o32 ABI is 32-bit (32-bit GPR width) while n32 is 64-bit (64-bit GPR 
> width).  The correspondence between the i386 ABI and the x86-64 x32 ABI is 
> analogous to these two ABIs.
>  How are these x86 ABIs handled WRT the user emulation mode; are they 
> analogous to the ARM ABIs you've mentioned?
> 
>> [I think we can use e_flags for that]
> 
>  The EF_MIPS_ABI2 `e_flags' bit denotes the n32 ABI.  The container format 
> is ELF32 obviously, because addressing is 32-bit with n32.

OK, I understand better. It looks like qemu-sparc32plus or qemu-ppc64abi32.
If this is the case, you're right we need different binaries.

>> I never did the change because I don't know where to find mipsn32
>> binaries to test my changes.
> 
>  I believe MIPS64 Debian is all n32.

Some readelf results:

mips64el/stretch

  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:   ELF64
  Flags:   0x80000007, noreorder, pic, cpic, mips64r2

mipsel/stretch

  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:   ELF32
  Flags:   0x70001007, noreorder, pic, cpic, o32, mips32r2

mips/stretch/bin

  Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
  Class:   ELF32
  Flags:   0x70001007, noreorder, pic, cpic, o32, mips32r2

So 32bit mips are all o32, 64bit is n32.

Are there any distros that are 32bit but n32?
Any binaries that need qemu-mipsn32 or qemu-mipsn32el?

Thanks,
Laurent

On Fri, 9 Nov 2018, Laurent Vivier wrote:

> >  I believe MIPS64 Debian is all n32.
> 
> Some readelf results:
> 
> mips64el/stretch
> 
>   Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
>   Class:   ELF64
>   Flags:   0x80000007, noreorder, pic, cpic, mips64r2

 Hmm, that's weird -- what executable did you check?  There may be some 
that are n64, or maybe they've switched (which I would applaud, FWIW).  I 
remember seeing mostly n32, with minimal support for n64, but that was a 
while ago -- jessie or suchlike, I believe.  Using MIPS64r2 as the base 
ISA also looks new to me, that used to be plain MIPS III, and some of 
Debian's MIPS build systems used to be either MIPS III (Lemote Loongson) 
or MIPS64r1 (Broadcom SiByte).

> Are there any distros that are 32bit but n32?

 You need 64-bit hardware for n32, so you can't do a 32-bit distribution 
with n32.  FAOD n32 is ILP32 with 64-bit `long long' and 64-bit stack 
slots both using the native 64-bit register width.

> Any binaries that need qemu-mipsn32 or qemu-mipsn32el?

 I'd expect at least the n32 dynamic loader (along with libc and some 
other essential DSOs) to be present with MIPS64 Debian.  Traditionally, 
under the FHS rules, it would be installed as /lib32/ld.so.1 (with the o32 
one as /lib/ld.so.1 and the n64 as /lib64/ld.so.1), but Debian uses their 
own multiarch filesystem layout standard, and offhand I don't remember 
what the paths are defined to there.

 Anyway, once you have tracked down the `ld.so.1' binary you can invoke it 
directly for some output, and it should be good enough for your smoke test 
purposes IIUC.

 I am away travelling through the end of this week and I have limited 
access to resources.  I can help more once I am back next week.

  Maciej

On Fri, 9 Nov 2018, Maciej W. Rozycki wrote:

> > Some readelf results:
> > 
> > mips64el/stretch
> > 
> >   Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
> >   Class:   ELF64
> >   Flags:   0x80000007, noreorder, pic, cpic, mips64r2
> 
>  Hmm, that's weird -- what executable did you check?  There may be some 
> that are n64, or maybe they've switched (which I would applaud, FWIW).  I 
> remember seeing mostly n32, with minimal support for n64, but that was a 
> while ago -- jessie or suchlike, I believe.  Using MIPS64r2 as the base 
> ISA also looks new to me, that used to be plain MIPS III, and some of 
> Debian's MIPS build systems used to be either MIPS III (Lemote Loongson) 
> or MIPS64r1 (Broadcom SiByte).

 OK, I definitely got this confused.  I did some checking and jessie 
didn't even have a 64-bit MIPS port.  I got their build systems right 
though, and the kernel is 64-bit for systems that support it.

> > Any binaries that need qemu-mipsn32 or qemu-mipsn32el?
> 
>  I'd expect at least the n32 dynamic loader (along with libc and some 
> other essential DSOs) to be present with MIPS64 Debian.  Traditionally, 
> under the FHS rules, it would be installed as /lib32/ld.so.1 (with the o32 
> one as /lib/ld.so.1 and the n64 as /lib64/ld.so.1), but Debian uses their 
> own multiarch filesystem layout standard, and offhand I don't remember 
> what the paths are defined to there.

 So with jessie you can install the `libc6-dev-mipsn32' package, which 
will get you n32 glibc development libraries and will pull the 
complementing n32 dynamic loader (at /lib32/ld.so.1 actually) and n32 
glibc shared libraries as well.

 Unfortunately multilib support files, such as the CRT files, seem to be 
missing from GCC for n32 or I cannot find them.  Otherwise you would be 
able to compile and link n32 binaries just by calling `gcc -mabi=n32'.  
Still the dynamic loader is directly runnable, as I noted above.

 HTH,

  Maciej