[Pkg-rust-maintainers] Bug#976374: Bug#973414: libmozjs-78-0: invalid opcodes when launching GDM on AMD Geode

Simon McVittie smcv at debian.org
Thu Dec 10 21:12:43 GMT 2020

On Thu, 10 Dec 2020 at 21:43:18 +0200, Martin-√Čric Racine wrote:
> I cannot help but wonder what platform defaults GCC uses on i386.

i686 without NOPL, according to
(which I believe is still current).

However, rust's interpretation of what "i686" means doesn't seem to be
the same as gcc's:

> This being said, if anyone asks me, non-PAE 686 ought to be a good
> enough baseline for i386. Most people who need something faster have
> moved onto amd64 or some other 64-bit platform. Meanwhile, i386 very
> much implies old hardware. As such, rising the baseline CPU would
> needlessly kill the usefulness of the port.

That's assuming that the only purpose of i386 is to have an OS you can
boot on 32-bit processors, but I suspect it's a lot more common this
decade to use i386 as a multiarch foreign architecture as a way to run
legacy 32-bit binaries on an x86_64 CPU, and a higher baseline would be
beneficial for that.

In particular, the current baseline doesn't assume SSE2, which
means floating-point calculations on i386 use the i387 instructions
(-mfpmath=387), which don't always give the same answers as other
architectures due to extended precision. A baseline with SSE2 would be
able to use -mfpmath=sse, which "should be considerably faster in the
majority of cases and avoid the numerical instability problems of 387
code" according to gcc documentation.

Ubuntu has dropped i386 as a bootable architecture, but continues to
compile a subset for multiarch use. I'm sure Debian will eventually do the
same - I don't know whether it'll be for bullseye or for a future release.

The way to influence these decisions, if you want to, would be to
volunteer to maintain the i386 port and be one of the people responsible
for fixing bugs like this.


More information about the Pkg-rust-maintainers mailing list