Bug#995194: libopenal1: i386 baseline violation

[Simon McVittie]

On Wed, 29 Sep 2021 at 22:41:03 +0200, bret curtis wrote:
> To be honest, if you're still running on hardware that is older than yourself
> then I would have to pragmatically ask if you or anyone actually runs
> openal-soft on that particular hardware platform.

While I agree with this, and I have suggested in the past that Debian's
baseline on i386 should reflect i386's major use case this decade as a
compatibility layer to run legacy 32-bit binaries[1] on x86_64 CPUs[2],
other people in the project have resisted that change on the basis that
they apparently do still use x86 hardware that is genuinely only 32-bit;
most vocally, we have people using AMD Geode CPUs, which are i686 minus
one non-essential opcode. As a result, Debian's current i386 baseline
is the instruction set of those Geode CPUs.

Early in the bookworm development cycle, gcc-11 briefly generated code
with CET (a control-flow security feature that makes use of opcodes that
were not supported on i686 and are "long NOPs" on all SSE-capable CPUs)
when building for i386, but this caused crashes on sufficiently old CPUs
and was reverted. If there is anything that will finally make us raise
the baseline at some point in future, it is probably going to be CET
(or rustc, which has trouble targeting such old i386 variants).

>     This can be disabled with the ALSOFT_ENABLE_SSE2_CODEGEN=FALSE
>     cmake option, which will let it use the compiler default, though it's
>     not recommended.

Debian policy is currently that we should do that, despite its performance
impact.

>     So disabling SSE2 codegen
>     will allow it to work for pre-SSE2 CPUs, but worsen 32-bit performance
>     for SSE2-capable CPUs

This is apparently what the project has chosen, even if only via
inertia. While I personally don't think this is necessarily a great
strategy, it is not a particularly high priority for me, so I have not
asked the Technical Committee[3] to overrule whoever it is that makes
this decision[4].

> So we either use the SSE extensions, or don't even bother shipping i386
> openal-soft.

Please continue to ship i386 openal-soft. 32-bit Wine needs it.

    smcv

[1] either proprietary native Linux binaries, 32-bit Windows binaries via
    32-bit Wine, or open source that is *still* not 32-bit-safe
[2] all x86_64 CPUs have MMX, SSE and SSE2
[3] disclosure: I am a member of the Technical Committee myself
[4] if we wanted to overrule whatever maintainers are responsible for
    setting the i386 baseline, the first step would be to find out who
    they are, since there is no i386 porting team, and the other obvious
    candidate (the gcc maintainer) seems to have wanted to raise the
    baseline but then been overruled by *someone*