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

Martin-Éric Racine martin-eric.racine at iki.fi
Thu Oct 13 07:15:25 BST 2022


This upstream commit should restore rustc defaults to something that
actually works on plain old 686:

https://github.com/rust-lang/rust/pull/100969

Martin-Éric

On Sat, Feb 20, 2021 at 4:24 PM Martin-Éric Racine
<martin-eric.racine at iki.fi> wrote:
>
> to 10. jouluk. 2020 klo 23.12 Simon McVittie (smcv at debian.org) kirjoitti:
> >
> > 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
> > https://www.debian.org/releases/stretch/i386/release-notes/ch-information.en.html#i386-is-now-almost-i686
> > (which I believe is still current).
> >
> > However, rust's interpretation of what "i686" means doesn't seem to be
> > the same as gcc's:
> > https://internals.rust-lang.org/t/is-pentium4-still-an-appropriate-base-cpu-for-i686/7353
> >
> > > 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.
>
> Elsewhere an upstream Rust contributor recommended that Debian uses
> the i585 target for Rust (and LLVM) on i386, instead of trying to
> downgrade the i686 target to produce pentium-pro code. He concedes
> that upstream might have made some unfortunate assumptions about what
> sort of CPU features are available for the generic i686 target  e.g
> SSE2, but he feels that Debian using the i586 target would make more
> sense if the goal is to produce code that definitely won't
> accidentally use unexpected opcodes.
>
> Martin-Éric



More information about the Pkg-rust-maintainers mailing list