Add a Docker image providing cross toolchain for the MIPS R5900 CPU
(used on the Sony PS2).
This image is based on Gentoo and the toolchain is built using crossdev.
Recipe from:
https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg03944.html
Suggested-by: Fredrik Noring <noring@nocrew.org>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
tests/docker/Makefile.include | 3 ++
.../gentoo-mipsr5900el-cross.docker | 35 +++++++++++++++++++
.../crossdev.conf | 5 +++
3 files changed, 43 insertions(+)
create mode 100644 tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker
create mode 100644 tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker.d/crossdev.conf
diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index 93b29ad823e..3d6306c7728 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -146,6 +146,9 @@ docker-image-debian-riscv64-cross: docker-image-debian10
docker-image-debian-s390x-cross: docker-image-debian10
docker-image-debian-sh4-cross: docker-image-debian10
docker-image-debian-sparc64-cross: docker-image-debian10
+docker-image-gentoo-mipsr5900el-cross: EXTRA_FILES:=$(addprefix \
+ $(SRC_PATH)/tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker.d/,\
+ crossdev.conf)
docker-image-travis: NOUSER=1
diff --git a/tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker b/tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker
new file mode 100644
index 00000000000..88ada20623d
--- /dev/null
+++ b/tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker
@@ -0,0 +1,35 @@
+#
+# Docker mipsel (r5900) cross-compiler target
+#
+# Using multi-stage builds, this image requires docker-17.05.0 or later.
+# (See: https://github.com/gentoo/gentoo-docker-images)
+#
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+# name the portage image
+FROM gentoo/portage:20201121 as portage
+
+# image is based on stage3-amd64
+FROM gentoo/stage3:latest
+
+# copy the entire portage volume in
+COPY --from=portage /var/db/repos/gentoo /var/db/repos/gentoo
+
+MAINTAINER Philippe Mathieu-Daudé <f4bug@amsat.org>
+
+# set CROSSDEV_OVERLAY to /usr/local/portage-crossdev
+RUN mkdir -p /usr/local/portage-crossdev/{profiles,metadata} && \
+ echo 'crossdev' > /usr/local/portage-crossdev/profiles/repo_name && \
+ echo 'masters = gentoo' > /usr/local/portage-crossdev/metadata/layout.conf && \
+ chown -R portage:portage /usr/local/portage-crossdev && \
+ mkdir -p /etc/portage/repos.conf
+ADD crossdev.conf /etc/portage/repos.conf/crossdev.conf
+
+RUN emerge -qv \
+ dev-vcs/git ">=dev-libs/glib-2.0" \
+ sys-devel/crossdev \
+ sys-libs/zlib dev-lang/python
+
+RUN crossdev -s4 -t mipsr5900el-unknown-linux-gnu
+
+ENV QEMU_CONFIGURE_OPTS --cross-prefix=mipsr5900el-unknown-linux-gnu-
diff --git a/tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker.d/crossdev.conf b/tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker.d/crossdev.conf
new file mode 100644
index 00000000000..b8fa368c1c3
--- /dev/null
+++ b/tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker.d/crossdev.conf
@@ -0,0 +1,5 @@
+[crossdev]
+location = /usr/local/portage-crossdev
+priority = 10
+masters = gentoo
+auto-sync = no
--
2.26.2
On Sun, Feb 14, 2021 at 06:59:02PM +0100, Philippe Mathieu-Daudé wrote:
> Add a Docker image providing cross toolchain for the MIPS R5900 CPU
> (used on the Sony PS2).
>
> This image is based on Gentoo and the toolchain is built using crossdev.
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 ?
>
> Recipe from:
> https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg03944.html
>
> Suggested-by: Fredrik Noring <noring@nocrew.org>
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> tests/docker/Makefile.include | 3 ++
> .../gentoo-mipsr5900el-cross.docker | 35 +++++++++++++++++++
> .../crossdev.conf | 5 +++
> 3 files changed, 43 insertions(+)
> create mode 100644 tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker
> create mode 100644 tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker.d/crossdev.conf
>
> diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
> index 93b29ad823e..3d6306c7728 100644
> --- a/tests/docker/Makefile.include
> +++ b/tests/docker/Makefile.include
> @@ -146,6 +146,9 @@ docker-image-debian-riscv64-cross: docker-image-debian10
> docker-image-debian-s390x-cross: docker-image-debian10
> docker-image-debian-sh4-cross: docker-image-debian10
> docker-image-debian-sparc64-cross: docker-image-debian10
> +docker-image-gentoo-mipsr5900el-cross: EXTRA_FILES:=$(addprefix \
> + $(SRC_PATH)/tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker.d/,\
> + crossdev.conf)
>
> docker-image-travis: NOUSER=1
>
> diff --git a/tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker b/tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker
> new file mode 100644
> index 00000000000..88ada20623d
> --- /dev/null
> +++ b/tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker
> @@ -0,0 +1,35 @@
> +#
> +# Docker mipsel (r5900) cross-compiler target
> +#
> +# Using multi-stage builds, this image requires docker-17.05.0 or later.
> +# (See: https://github.com/gentoo/gentoo-docker-images)
> +#
> +# SPDX-License-Identifier: GPL-2.0-or-later
> +
> +# name the portage image
> +FROM gentoo/portage:20201121 as portage
> +
> +# image is based on stage3-amd64
> +FROM gentoo/stage3:latest
> +
> +# copy the entire portage volume in
> +COPY --from=portage /var/db/repos/gentoo /var/db/repos/gentoo
> +
> +MAINTAINER Philippe Mathieu-Daudé <f4bug@amsat.org>
> +
> +# set CROSSDEV_OVERLAY to /usr/local/portage-crossdev
> +RUN mkdir -p /usr/local/portage-crossdev/{profiles,metadata} && \
> + echo 'crossdev' > /usr/local/portage-crossdev/profiles/repo_name && \
> + echo 'masters = gentoo' > /usr/local/portage-crossdev/metadata/layout.conf && \
> + chown -R portage:portage /usr/local/portage-crossdev && \
> + mkdir -p /etc/portage/repos.conf
> +ADD crossdev.conf /etc/portage/repos.conf/crossdev.conf
> +
> +RUN emerge -qv \
> + dev-vcs/git ">=dev-libs/glib-2.0" \
> + sys-devel/crossdev \
> + sys-libs/zlib dev-lang/python
> +
> +RUN crossdev -s4 -t mipsr5900el-unknown-linux-gnu
> +
> +ENV QEMU_CONFIGURE_OPTS --cross-prefix=mipsr5900el-unknown-linux-gnu-
> diff --git a/tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker.d/crossdev.conf b/tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker.d/crossdev.conf
> new file mode 100644
> index 00000000000..b8fa368c1c3
> --- /dev/null
> +++ b/tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker.d/crossdev.conf
> @@ -0,0 +1,5 @@
> +[crossdev]
> +location = /usr/local/portage-crossdev
> +priority = 10
> +masters = gentoo
> +auto-sync = no
> --
> 2.26.2
>
>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Mon, Feb 15, 2021 at 11:59:57AM +0000, Daniel P. Berrangé wrote: > On Sun, Feb 14, 2021 at 06:59:02PM +0100, Philippe Mathieu-Daudé wrote: > > Add a Docker image providing cross toolchain for the MIPS R5900 CPU > > (used on the Sony PS2). > > > > This image is based on Gentoo and the toolchain is built using crossdev. > > 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 ? Is it necessary to rebuild the toolchain every time? Also, perhaps a generic MIPS suite can be used; it shouldn't to necessary to have one specifically made for the R5900 (except libc, if needed, I guess). As an alternative, TobiX at Github made an R5900 Docker image last year <https://github.com/frno7/linux/issues/33#issuecomment-632284209>, perhaps it could be useful somehow? Fredrik
On 2/15/21 2:45 PM, Fredrik Noring wrote: > On Mon, Feb 15, 2021 at 11:59:57AM +0000, Daniel P. Berrangé wrote: >> On Sun, Feb 14, 2021 at 06:59:02PM +0100, Philippe Mathieu-Daudé wrote: >>> Add a Docker image providing cross toolchain for the MIPS R5900 CPU >>> (used on the Sony PS2). >>> >>> This image is based on Gentoo and the toolchain is built using crossdev. >> >> 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 ? > > Is it necessary to rebuild the toolchain every time? No. > Also, perhaps a > generic MIPS suite can be used; it shouldn't to necessary to have one > specifically made for the R5900 (except libc, if needed, I guess). We want it to build TCG tests. If we can link them, that should be OK. > As an alternative, TobiX at Github made an R5900 Docker image last year > <https://github.com/frno7/linux/issues/33#issuecomment-632284209>, > perhaps it could be useful somehow? Thanks, I'll have a look. Regards, Phil.
On 2/20/21 9:01 PM, Philippe Mathieu-Daudé wrote: > On 2/15/21 2:45 PM, Fredrik Noring wrote: >> On Mon, Feb 15, 2021 at 11:59:57AM +0000, Daniel P. Berrangé wrote: >>> On Sun, Feb 14, 2021 at 06:59:02PM +0100, Philippe Mathieu-Daudé wrote: >>>> Add a Docker image providing cross toolchain for the MIPS R5900 CPU >>>> (used on the Sony PS2). >>>> >>>> This image is based on Gentoo and the toolchain is built using crossdev. >>> >>> 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. >> >> Is it necessary to rebuild the toolchain every time? > > No. > >> Also, perhaps a >> generic MIPS suite can be used; it shouldn't to necessary to have one >> specifically made for the R5900 (except libc, if needed, I guess). > > We want it to build TCG tests. If we can link them, that should be OK. > >> As an alternative, TobiX at Github made an R5900 Docker image last year >> <https://github.com/frno7/linux/issues/33#issuecomment-632284209>, >> perhaps it could be useful somehow? > > Thanks, I'll have a look. > > Regards, > > Phil. >
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, 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). HTH, Maciej
Hi Maciej,
On 3/12/21 6:05 PM, 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,
The previous maintainer let the QEMU MIPS codebase with the R5900 code
unreachable. I'm trying to see if I can get a closure on Fredrik work
before removing it, because there is no point in maintaining unreachable
code.
QEMU uses Docker images of distributions to cross-compile its tests.
Currently all Linux cross-tests are built using Debian based images.
Daniel asked me to see if I can use our current Debian based image
to build the r5900 tests, instead of adding yet another one (based
on Gentoo).
> 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.
With the Debian toolchain I get:
/usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No
such file or directory
#include <bits/libc-header-start.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~
> 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.
Shouldn't -march=r5900 imply -march=mips3?
> 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).
Regards,
Phil.
On Fri, 12 Mar 2021, Philippe Mathieu-Daudé wrote:
> > 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.
>
> With the Debian toolchain I get:
>
> /usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No
> such file or directory
> #include <bits/libc-header-start.h>
> ^~~~~~~~~~~~~~~~~~~~~~~~~~
You need to have a soft-float multilib available. You can use:
$ gcc -print-multi-lib
to see what multilibs are available. You'd have to have one that includes
`-msoft-float' and `-mabi=n32' both at a time. If there's no such one,
then you'll have to build your own cross-compiler (including soft-float
libc).
> > 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.
>
> Shouldn't -march=r5900 imply -march=mips3?
It does:
MIPS_CPU ("r5900", PROCESSOR_R5900, 3, 0)
however it is a distinct architecture owing to the differences from plain
MIPS III ISA, and obviously the compiler and the assembler both know that.
Maciej
On Friday, 12 March 2021, Maciej W. Rozycki wrote: > On Fri, 12 Mar 2021, Philippe Mathieu-Daudé wrote: > > > > 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. > > > > With the Debian toolchain I get: > > > > /usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No > > such file or directory > > #include <bits/libc-header-start.h> > > ^~~~~~~~~~~~~~~~~~~~~~~~~~ > > You need to have a soft-float multilib available. You can use: > > $ gcc -print-multi-lib > > to see what multilibs are available. You'd have to have one that includes > `-msoft-float' and `-mabi=n32' both at a time. If there's no such one, > then you'll have to build your own cross-compiler (including soft-float > libc). Perhaps, for the purpose of this test, if Debian doesn't have soft-float and can't be recompiled, the -march=r5900 option could be omitted to instead have objcopy (or even xxd) fix up the ELF to have it appear as an R5900 program afterwards? DMULT within an R5900 ELF would still be tested, as intended, even if there might be some additional non-R5900 instructions in it as well (which R5900/QEMU is supposed to accept anyway, no?). On Friday, 12 March 2021, Philippe Mathieu-Daudé wrote: > On 3/12/21 7:24 PM, Fredrik Noring wrote: > > 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. > > Yes, this works with Gentoo. But building the Gentoo's r5900 toolchain > container is too expensive for our CI, so I was trying with Debian, but > with no luck so far. Why rebuild the Gentoo toolchain so often, then? :) A couple of times per year, and on special occasions (such as security updates or wanted feature extensions), would be enough, I think. Gentoo has rolling releases, as opposed to major releases, and old stuff (GCC in particular) can coexist with modern counterparts via package slots, or in overlays, etc. Of course, one might find it practical to use Debian for everything anyhow. Fredrik
Hi Maciej, Alex,
On 3/12/21 9:04 PM, Maciej W. Rozycki wrote:
> On Fri, 12 Mar 2021, Philippe Mathieu-Daudé wrote:
>
>>> 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.
>>
>> With the Debian toolchain I get:
>>
>> /usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No
>> such file or directory
>> #include <bits/libc-header-start.h>
>> ^~~~~~~~~~~~~~~~~~~~~~~~~~
>
> You need to have a soft-float multilib available. You can use:
>
> $ gcc -print-multi-lib
>
> to see what multilibs are available. You'd have to have one that includes
> `-msoft-float' and `-mabi=n32' both at a time. If there's no such one,
> then you'll have to build your own cross-compiler (including soft-float
> libc).
For Alex:
I tried Maciej suggestion using:
-- >8 --
diff --git a/tests/docker/dockerfiles/debian10.docker
b/tests/docker/dockerfiles/debian10.docker
index d034acbd256..42933538a49 100644
--- a/tests/docker/dockerfiles/debian10.docker
+++ b/tests/docker/dockerfiles/debian10.docker
@@ -23,6 +23,7 @@ RUN apt update && \
ccache \
clang \
dbus \
+ gcc-multilib \
gdb-multiarch \
gettext \
git \
---
Then used qemu/debian-mipsel-cross.
Maciej, I tried your suggestion as follow:
$ mipsel-linux-gnu-gcc --version
mipsel-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ mipsel-linux-gnu-gcc -print-multi-lib
.;
n32;@mabi=n32
64;@mabi=64
soft-float is not listed, but:
$ touch a.c
$ mipsel-linux-gnu-gcc -mabi=n32 -march=r5900 -msoft-float -c a.c
$ file a.o
a.o: ELF 32-bit LSB relocatable, MIPS, N32 MIPS-III version 1 (SYSV),
not stripped
$ readelf -h a.o
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 456 (bytes into file)
Flags: 0x20920026, pic, cpic, abi2, 5900,
mips3
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 13
Section header string table index: 12
So we can compile, but:
$ mipsel-linux-gnu-gcc -mabi=n32 -march=r5900 -msoft-float -L
/usr/lib/mipsel-linux-gnu tests/tcg/mips/test-r5900-dmult.c
/usr/lib/gcc-cross/mipsel-linux-gnu/8/../../../../mipsel-linux-gnu/bin/ld:
/usr/lib/../lib32/Scrt1.o: relocations in generic ELF (EM: 3)
/usr/lib/gcc-cross/mipsel-linux-gnu/8/../../../../mipsel-linux-gnu/bin/ld:
/usr/lib/../lib32/Scrt1.o: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
$ mipsel-linux-gnu-readelf -h /usr/lib/mipsel-linux-gnu/Scrt1.o
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 908 (bytes into file)
Flags: 0x70001007, noreorder, pic, cpic,
o32, mips32r2
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 15
Section header string table index: 14
The multilib documentation is scarce :)
Also I wondered if I could abuse the linker a bit, knowing the resulting
binary would be crap due to ABI mismatch, and got:
$ mipsel-linux-gnu-gcc -march=r5900 -msoft-float -o test-r5900-dmult
test-r5900-dmult.o
collect2: fatal error: ld terminated with signal 11 [Segmentation
fault], core dumped
compilation terminated.
/usr/lib/gcc-cross/mipsel-linux-gnu/8/../../../../mipsel-linux-gnu/bin/ld:
test-r5900-dmult.o: ABI is incompatible with that of the selected emulation
/usr/lib/gcc-cross/mipsel-linux-gnu/8/../../../../mipsel-linux-gnu/bin/ld:
failed to merge target specific data of file test-r5900-dmult.o
/usr/lib/gcc-cross/mipsel-linux-gnu/8/../../../../mipsel-linux-gnu/bin/ld:
BFD (GNU Binutils for Debian) 2.31.1 assertion fail
../../bfd/elfxx-mips.c:3566
It seems Debian default packages aren't ready for QEMU needs.
Alex, the other options I'm thinking of are:
- Have you build/upload the gentoo-mipsr5900el-cross container
- Commit the test-r5900-dmult binary to the repository
- Craft a test-r5900-dmult in assembler without libc:
$ mipsel-linux-gnu-gcc -mabi=n32 -march=r5900 -msoft-float -o a a.o
-nostdlib -emain
$ readelf -h a
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0x102f0
Start of program headers: 52 (bytes into file)
Start of section headers: 1508 (bytes into file)
Flags: 0x20920026, pic, cpic, abi2, 5900,
mips3
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 9
Size of section headers: 40 (bytes)
Number of section headers: 17
Section header string table index: 16
- Do not include r5900 test in mainstream QEMU
What do you think?
Phil.
On Wed, 17 Mar 2021, Philippe Mathieu-Daudé wrote: > Maciej, I tried your suggestion as follow: > > $ mipsel-linux-gnu-gcc --version > mipsel-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0 > Copyright (C) 2018 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > $ mipsel-linux-gnu-gcc -print-multi-lib > .; > n32;@mabi=n32 > 64;@mabi=64 OK, so these are for the three ABIs Linux support, plain. You'd have to bootstrap your own compiler and either reconfigure it at least for n32 with a `-msoft-float' multilib, or build a non-multilib compiler for this ABI variant. Either way including glibc which to the best of my knowledge does support soft-float MIPS configurations. > soft-float is not listed, but: > > $ touch a.c > $ mipsel-linux-gnu-gcc -mabi=n32 -march=r5900 -msoft-float -c a.c > $ file a.o > a.o: ELF 32-bit LSB relocatable, MIPS, N32 MIPS-III version 1 (SYSV), > not stripped > $ readelf -h a.o > ELF Header: > Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 > Class: ELF32 > Data: 2's complement, little endian > Version: 1 (current) > OS/ABI: UNIX - System V > ABI Version: 0 > Type: REL (Relocatable file) > Machine: MIPS R3000 > Version: 0x1 > Entry point address: 0x0 > Start of program headers: 0 (bytes into file) > Start of section headers: 456 (bytes into file) > Flags: 0x20920026, pic, cpic, abi2, 5900, > mips3 > Size of this header: 52 (bytes) > Size of program headers: 0 (bytes) > Number of program headers: 0 > Size of section headers: 40 (bytes) > Number of section headers: 13 > Section header string table index: 12 > > So we can compile, but: Yes, all code models are always available for compilation (you can choose the default though). We (ab)use this feature for instance to build the Linux kernel, which obviously uses the bare metal non-PIC model. > $ mipsel-linux-gnu-gcc -mabi=n32 -march=r5900 -msoft-float -L > /usr/lib/mipsel-linux-gnu tests/tcg/mips/test-r5900-dmult.c > /usr/lib/gcc-cross/mipsel-linux-gnu/8/../../../../mipsel-linux-gnu/bin/ld: > /usr/lib/../lib32/Scrt1.o: relocations in generic ELF (EM: 3) > /usr/lib/gcc-cross/mipsel-linux-gnu/8/../../../../mipsel-linux-gnu/bin/ld: > /usr/lib/../lib32/Scrt1.o: error adding symbols: file in wrong format > collect2: error: ld returned 1 exit status Yes, the problem is in the missing runtime, and whatever GCC defaults to is not link-compatible. The message from the linker indicates it couldn't have chosen a MIPS emulation at all even. > $ mipsel-linux-gnu-readelf -h /usr/lib/mipsel-linux-gnu/Scrt1.o > ELF Header: > Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 > Class: ELF32 > Data: 2's complement, little endian > Version: 1 (current) > OS/ABI: UNIX - System V > ABI Version: 0 > Type: REL (Relocatable file) > Machine: MIPS R3000 > Version: 0x1 > Entry point address: 0x0 > Start of program headers: 0 (bytes into file) > Start of section headers: 908 (bytes into file) > Flags: 0x70001007, noreorder, pic, cpic, > o32, mips32r2 > Size of this header: 52 (bytes) > Size of program headers: 0 (bytes) > Number of program headers: 0 > Size of section headers: 40 (bytes) > Number of section headers: 15 > Section header string table index: 14 That is a plain o32 ABI object. > The multilib documentation is scarce :) Ask questions. :) > Also I wondered if I could abuse the linker a bit, knowing the resulting > binary would be crap due to ABI mismatch, and got: > > $ mipsel-linux-gnu-gcc -march=r5900 -msoft-float -o test-r5900-dmult > test-r5900-dmult.o > collect2: fatal error: ld terminated with signal 11 [Segmentation > fault], core dumped > compilation terminated. > /usr/lib/gcc-cross/mipsel-linux-gnu/8/../../../../mipsel-linux-gnu/bin/ld: > test-r5900-dmult.o: ABI is incompatible with that of the selected emulation > /usr/lib/gcc-cross/mipsel-linux-gnu/8/../../../../mipsel-linux-gnu/bin/ld: > failed to merge target specific data of file test-r5900-dmult.o > /usr/lib/gcc-cross/mipsel-linux-gnu/8/../../../../mipsel-linux-gnu/bin/ld: > BFD (GNU Binutils for Debian) 2.31.1 assertion fail > ../../bfd/elfxx-mips.c:3566 This looks like a linker bug, it's not supposed to report assertion failures let alone crash even if fed with rubbish. However version 2.31.1 is very old for any kind of odd experiments. Would you be able to try the current trunk? If that still shows the crash would you mind filing a bug with a full recipe to reproduce it at <https://sourceware.org/bugzilla/>? Regardless you can try fooling the linker by stripping the `.gnu.attributes' and `.MIPS.abiflags' sections from test-r5900-dmult.o with `objcopy'. This will make the linker consider it a legacy object with no float mode annotation. This does not answer the question implied by the choice I have given as to whether you actually need to use `-march=r5900 -msoft-float' with these compilations or whether plain `-march=mips3' will suffice. I think it will do, as at this point we only have minimal R5900 support in the compiler and Linux is supposed to emulate the MIPS III instructions missing from the architecture, including full IEEE 754 FP. So the use of `-march=r5900' does not appear to buy us anything. And any R5900-specific assembly can be wrapped into an appropriate pseudo-op sequence involving `.set arch=r5900'. I think this approach will enable forward progress. Maciej
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
On 3/12/21 7:24 PM, Fredrik Noring wrote:
> 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.
Yes, this works with Gentoo. But building the Gentoo's r5900 toolchain
container is too expensive for our CI, so I was trying with Debian, but
with no luck so far.
I'll test the other image your suggested elsewhere and see if Daniel is
OK with it (I doubt because this is not an "official" image).
Thanks,
Phil.
© 2016 - 2025 Red Hat, Inc.