Bug#973414: libmozjs-78-0: invalid opcodes when launching GDM on AMD Geode

[Simon McVittie]

Control: reassign 973414 rustc
Control: reassign 976374 rustc
Control: forcemerge 973414 976374
Control: retitle 973414 rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386
Control: affects 973414 + libmozjs-78-0 src:mozjs78 librsvg2-2 src:librsvg

On Thu, 10 Dec 2020 at 20:02:42 +0200, Martin-Éric Racine wrote:
> Core was generated by `/usr/bin/gnome-shell'.
> Program terminated with signal SIGILL, Illegal instruction.
> #0  0xb5500d08 in compiler_builtins::int::udiv::__udivmoddi4 () from
> /usr/lib/i386-linux-gnu/libmozjs-78.so.0
> [Current thread is 1 (Thread 0xb15c9b40 (LWP 861))]
> (gdb) bt full
> #0  0xb5500d08 in compiler_builtins::int::udiv::__udivmoddi4 () from
> /usr/lib/i386-linux-gnu/libmozjs-78.so.0
> No symbol table info available.

This looks like Rust code, presumably compiled from something like
https://sources.debian.org/src/rustc/1.48.0+dfsg1-1/vendor/compiler_builtins/src/int/udiv.rs/

Debian's rustc has a patch to reduce the i386 baseline from upstream's
pentium4 to pentiumpro
https://sources.debian.org/src/rustc/1.48.0+dfsg1-1/debian/patches/d-i686-baseline.patch/
but apparently that's not sufficient for a Geode LX. i686 is in a weird
situation where the Pentium Pro was the *first* i686 CPU, but is not a
*baseline* i686 CPU.

Presumably the root cause of #976374 in librsvg, which also contains
Rust code, is the same.

> > I'm sure you know more than I do about the finer points of the x86
> > instruction set and how opcodes map to CPU flags and architecture
> > extensions.
> 
> Sadly not. I only remember that the Geode LX is 1 instruction short of
> a standard 686.

There has been discussion on the debian-release mailing list about the
extent to which 32-bit x86 can be supported in the future, which might
be relevant to your interests. It seems unlikely that i386 will survive
as a full port providing a bootable system for the benefit of older
hardware like the Geode unless there are enough volunteers for an i386
porting team with knowledge of its quirks (i387 FPU, etc.) to be able
to fix things like this.

    smcv