Re: [RFC PATCH 32/42] docker: Add gentoo-mipsr5900el-cross image

[Fredrik Noring]

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