[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 32/42] docker: Add gentoo-mipsr5900el-cross image
From: |
Fredrik Noring |
Subject: |
Re: [RFC PATCH 32/42] docker: Add gentoo-mipsr5900el-cross image |
Date: |
Fri, 12 Mar 2021 19:24:08 +0100 |
On Friday, 12 March 2021, Maciej W. Rozycki wrote:
> On Fri, 12 Mar 2021, Philippe Mathieu-Daudé wrote:
>
> > >>> Is there any way we can do this with a distro that isn't Gentoo
> > >>> so that we can get a container build that is fast enough to be
> > >>> useful for CI ?
> >
> > Using the Debian cross image I get:
> >
> > /home/phil/source/qemu/tests/docker/docker.py --engine auto cc --cc
> > mips64el-linux-gnuabi64-gcc -i qemu/debian-mips64el-cross -s
> > /home/phil/source/qemu -- -Wall -Werror -O0 -g -fno-strict-aliasing
> > -mabi=n32 -march=r5900
> > /home/phil/source/qemu/tests/tcg/mips/test-r5900-dmult.c -o
> > test-r5900-dmult -static
> > cc1: error: unsupported combination: -march=r5900 -mhard-float
> > -mdouble-float
> >
> > No clue what is setting '-mhard-float -mdouble-float' yet.
>
> The R5900 has an FPU that only supports the single floating-point format.
> It's also not an IEEE 754 format. The Linux kernel ABI does support the
> double and also the single floating-point format, both compliant with IEEE
> 754.
>
> In the absence of a suitable FPU emulation code included with the kernel
> will handle the missing instructions (you can use the `nofpu' kernel
> parameter to force that in the presence of an FPU too). Beware however
> that a recent change to the Linux kernel made FPU emulation code optional
> to suit some deeply embedded applications known never to use FPU machine
> instructions.
>
> NB the presence of emulation is always required for MIPS ISA compliance
> if FPU machine instructions are ever to be used in a given application,
> because operations are allowed to trap regardless and rely on emulation.
>
> I don't know what you are trying to achieve,
I believe Philippe is trying to compile
https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg04565.html
testing this:
The R5900 reports itself as MIPS III but does not implement DMULT.
Verify that DMULT is emulated properly in user mode by multiplying
two 64-bit numbers to produce a 128-bit number.
with this piece of code (notice the mips3 ISA directive for DMULT):
/*
* Test DMULT.
*/
#include <stdio.h>
#include <inttypes.h>
#include <assert.h>
struct hi_lo { int64_t hi; uint64_t lo; };
static struct hi_lo dmult(int64_t rs, int64_t rt)
{
int64_t hi;
uint64_t lo;
/*
* The R5900 reports itself as MIPS III but does not implement DMULT.
* Verify that DMULT is emulated properly in user mode.
*/
__asm__ __volatile__ (
" .set mips3\n"
" dmult %2, %3\n"
" mfhi %0\n"
" mflo %1\n"
: "=r" (hi), "=r" (lo)
: "r" (rs), "r" (rt));
return (struct hi_lo) { .hi = hi, .lo = lo };
}
int main()
{
/* Verify that multiplying two 64-bit numbers yields a 128-bit number. */
struct hi_lo r = dmult(2760727302517, 5665449960167);
assert(r.hi == 847887);
assert(r.lo == 7893651516417804947);
return 0;
}
> but your two options to choose from are:
>
> 1. Build for the soft-float ABI (`-msoft-float') where any FP calculations
> are compiled such as to be made by the CPU using integer arithmetic.
>
> 2. Build for a generic MIPS ISA, for the R5900/n32 that would be MIPS III
> (`-march=mips3'), and rely on the kernel FPU emulation. Note that some
> integer MIPS III operations are missing too from the R5900 and have to
> be emulated by the kernel for MIPS/Linux n32 psABI compliance (an
> implementation can be pinched from an old libgcc version that was still
> under GNU GPLv2 or another algorithm reused, e.g. my `__div64_32' piece
> easily adapted).
So qemu/tests/tcg/mips/Makefile.target is patched with
# r5900 is only 64 bit little-endian
ifneq ($(findstring 64el,$(TARGET_NAME)),)
MIPS_TESTS += test-r5900-dmult
test-r5900-dmult: CFLAGS += -mabi=n32 -march=r5900
endif
I didn't have issues with the -mhard-float -mdouble-float flags at the time,
and I didn't use mips64el-linux-gnuabi64-gcc for Debian.
Fredrik