On Mon, 10 Jun 2024 at 20:17:27 +0500, Andrey Rakhmatullin wrote:
> On Mon, Jun 10, 2024 at 04:02:54PM +0100, Simon McVittie wrote:
> > several important upstreams no longer consider i386 to be useful (and
> > especially i386-without-SSE2), so so the burden of supporting 32-bit
> > CPUs in modern software will fall on the downstream developers who have
> > chosen that their aim is to support 32-bit CPUs.
>
> I assume such software already has this status on Debian i386 (and so is
> either not built there or supported only by the maintainer, or maybe built
> with a raised baseline) so there should be no regression here
Some concrete examples:
* Packages built with -fcf-protection (Intel CET) require CPU support
for "long NOP" opcodes which are, or used to be, non-baseline.
This is a security hardening measure, so if we disable it in order
to respect the documented baseline, the result is that our binaries
are less secure than they could be (fewer mitigations for exploits)
on CPUs where those opcodes actually *are* supported. (That's what
started this thread: sudo enables this hardening.)
* nodeJS, Qt5WebEngine and others have a known baseline violation by using
and requiring SSE2 internally, which they document by depending on
sse2-support. I thought Chromium did this too, but maybe it either
doesn't do that any more, or still has the baseline violation but
doesn't document it.
* Packages built with rustc (notably Firefox and librsvg) had a known
baseline violation in the past (they would crash with an illegal
instruction on i586) which was made officially not-a-bug by raising the
baseline to i686.
* In packages with test suites that compare the results of floating-point
calculations at a high precision (such as librsvg), the fact that we
target the legacy i387 FPU (which has 80-bit excess precision) rather
than SSE2 (which has 64-bit IEEE precision) has caused a lot of extra
work for maintainers in the past, due to tests getting a result on i386
that differs from the result on every other platform we support.
* Some third-party software like Steam does not follow our baselines,
and unconditionally requires newer CPU features. (Not a concern for
Steam on i386 any more, because Steam now requires a 64-bit CPU, so
bookworm's steam-installer is intentionally not installable on purely
32-bit systems - but Steam will not actually work on a baseline *64-bit*
CPU any more.)
smcv
