Re: [PATCH v2 21/30] Deprecate 32 bit big-endian MIPS

[Daniel P . Berrangé]

On Fri, Sep 16, 2022 at 12:10:30PM +0200, Pierre Muller wrote:
> 
> 
> Le 16/09/2022 à 10:38, Richard Henderson a écrit :
> > On 9/16/22 10:08, Pierre Muller wrote:
> > > 
> > >     I am using gcc230 machine for the gcc compile farm.
> > > 
> > >     This is a big endian mips64 machine runnig Debian Buster.
> > > 
> > > When compiling the qemu 7.1.0 release source,
> > > the generated binaries are 32-bit mips binaries,
> > > and I did not find out how to generate a 64-bit versions
> > > of the executables.
> > 
> > Yes, that host seems to have been installed with the o32 abi instead of the 
> > n64 (or n32) abi.
> 
> Indeed,
> > >     As mips32 seems to still be the default arch that gcc uses,
> > > I don't really understand the idea of depreciating big endian mips32.
> > > 
> > > Is this solely related to cross-compilation issues?
> > 
> > Yes.  Even gcc230 is fairly small for actually compiling qemu, it takes 
> > many hours.  So
> > for many hosts we rely on cross-compilation from x86_64.
> > 
> > For that, we rely on the set of cross-compilers built by Debian 11 
> > (bullseye) plus (!) the
> > host libraries for that platform.  We cannot simply rely on 
> > crossbuild-essential-mips
> > because building qemu requires many more system libraries than just libc.
> > 
> > In https://www.debian.org/releases/bullseye/, you'll note that big-endian 
> > mips is not
> > listed, so we are now missing those system libraries.
> 
>  So this is not limited to mips32, as big endian mips64 is also not supported 
> anymore in bulleye...

Right, so as a general policy, for a platform target to be considered
fully supported, there needs to be a non-EOL (end of life) OS distro
with which we can run automated CI. In terms of unusual architectures,
Debian has historically been our best bet for being able to put together
container images suitable for running CI.

When even Debian has dropped an architecture, as well as removing our
ability to do CI, it is also a sign of the architectures diminishing
importance to the ecosystem as a whole. This makes it hard to justify
investing in figuring out new CI options, though we're open to suggestions
and help if people can point to non-EOL platforms that can be used,
especially if container based.

We don't wish to use end of life platforms for CI, since we periodically
intend to increase our minimum required versions of 3rd party libraries,
based on what current OS ship & testing using EOL platforms would prevent
that.

FWIW: https://www.qemu.org/docs/master/about/build-platforms.html

> > We are not intending to *remove* support for big-endian mips, as 99% of the 
> > code paths are
> > shared with little-endian mips, which we can continue to test.  But we are 
> > now saying that
> > big-endian mips is not "supported" and might break.
> 
>   Thank you for your answer and the clarifications!

In practical terms the lack of CI means that we can't guarantee that a
new QEMU release will compile successfully. We're handing off responsbility
for keeping it working to any interested users to do adhoc testing of their
own. We can still accept bug reports & patches when people discover problems.

With 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 :|