Debian Bug report logs - #973414
rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Martin-Éric Racine <martin-eric.racine@iki.fi>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: libmozjs-78-0: invalid opcodes in libmozjs when launching GDM3

Date: Fri, 30 Oct 2020 10:35:21 +0200

Package: libmozjs-78-0
Version: 78.3.0-2
Severity: important

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

[  165.903916] traps: gnome-shell[869] trap invalid opcode ip:b5518f8a sp:b17d6d80 error:0 in libmozjs-78.so.78.3.0[b4b98000+98c000]
[  186.163963] traps: gnome-shell[931] trap invalid opcode ip:b55d4f8a sp:b1892d80 error:0 in libmozjs-78.so.78.3.0[b4c54000+98c000]
[  188.417729] traps: gnome-shell[936] trap invalid opcode ip:b554df8a sp:b180bd80 error:0 in libmozjs-78.so.78.3.0[b4bcd000+98c000]
[  204.840919] traps: gnome-session-f[939] trap invalid opcode ip:b4e7f86a sp:bfcc1460 error:0 in librsvg-2.so.2.47.0[b4e6d000+5b7000]
[  205.334962] rfkill: input handler disabled
[  206.914176] traps: gjs[1056] trap invalid opcode ip:b74f9f8a sp:b3f6d040 error:0 in libmozjs-78.so.78.3.0[b6b79000+98c000]
[  217.300333] rfkill: input handler enabled
[  233.628071] traps: gnome-shell[1132] trap invalid opcode ip:b55c2f8a sp:b1880d80 error:0 in libmozjs-78.so.78.3.0[b4c42000+98c000]
[  237.282981] traps: gnome-shell[1145] trap invalid opcode ip:b554bf8a sp:b1809d80 error:0 in libmozjs-78.so.78.3.0[b4bcb000+98c000]
[  251.475717] traps: gnome-session-f[1148] trap invalid opcode ip:b4e5186a sp:bff460f0 error:0 in librsvg-2.so.2.47.0[b4e3f000+5b7000]
[  252.530390] rfkill: input handler disabled
[  252.935696] traps: gjs[1252] trap invalid opcode ip:b752cf8a sp:b3fa0040 error:0 in libmozjs-78.so.78.3.0[b6bac000+98c000]
[  257.741066] rfkill: input handler enabled
[  273.153629] traps: gnome-shell[1319] trap invalid opcode ip:b5570f8a sp:b182ed80 error:0 in libmozjs-78.so.78.3.0[b4bf0000+98c000]


- -- System Information: Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (1000, 'testing-debug'), (1000, 'testing'), (500, 'stable')
Architecture: i386 (i586)

Kernel: Linux 5.9.0-1-686 (SMP w/1 CPU thread)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libmozjs-78-0 depends on:
ii  libc6       2.31-4
ii  libgcc-s1   10.2.0-15
ii  libicu67    67.1-4
ii  libstdc++6  10.2.0-15
ii  tzdata      2020d-1
ii  zlib1g      1:1.2.11.dfsg-2

libmozjs-78-0 recommends no packages.

libmozjs-78-0 suggests no packages.

- -- no debconf information

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAl+b0EIACgkQrh+Cd8S0
17a2QhAAhlMV2BrAoPmp2rCI/BUU5KnSQ+qlSFDz4Kd8to6RA+dwD5nzPcJAoBVK
IueznUCRvFMke8J7bJWnmZfOWnhA+7NGfl4sPitKD9b5V1Qe2TK5sxt16o5RvrR/
MIOEL9eJSgpToGZisToi+zKwbTmqLz4QuI9p4L6Fr27+sHVUpoyts7aFdsh2q9IL
XowB36SzfFxg8Xfu0AA6EilPqV54j/WGUHvI7MJH+gAOCDK9FkijsoxiwWKtanRe
DhjLrlelR+LgBONRN5LlcFHfHcd1pJJdMVtyt6mHMpc0FcY7QUb48ke5o2LBExb4
DAVmJBz/5zSezv+S6kpcgt2EJwgnGs6jkNiYjXQJj+NOypm0M2NiGovV2+OuuMzL
pbwrN/MjM8X6YClmUB1YYVrXUEyH3Leu3vILZ/w6sxN1Qgf6QVFfMVYoSwH8K4dh
NEUZkYKhEAsX0HBSaNvoUFhC0X8hH3NEmeSmwsb5vLcwZ8NEPMwS9efhnoaqWbzZ
vH3PHf4P1d+aAVPrLBU1ZGRGJoWooAzvNb7JUMBdt3tmKveXSetNxSRi1qa8kMRb
38dF3g7Z+kLoY3a4Sv6syi30YDeSvFd4VdzV/JjVvL+BnRRW77zUsyhFTuO2D3hc
l6st16Il04XEAKrp92sHsv8Rk0cf5X4vJJ5GPSo0iWCxacPhYU4=
=rnps
-----END PGP SIGNATURE-----

Message #10 received at 973414@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Martin-Éric Racine <martin-eric.racine@iki.fi>, 973414@bugs.debian.org

Cc: debian-gcc@lists.debian.org

Subject: Re: Bug#973414: libmozjs-78-0: invalid opcodes in libmozjs when launching GDM3

Date: Fri, 30 Oct 2020 11:49:57 +0000

Control: tags -1 + moreinfo

On Fri, 30 Oct 2020 at 10:35:21 +0200, Martin-Éric Racine wrote:
> [  165.903916] traps: gnome-shell[869] trap invalid opcode ip:b5518f8a sp:b17d6d80 error:0 in libmozjs-78.so.78.3.0[b4b98000+98c000]

Which specific x86 CPU is this? I see `uname -m` is i586 rather than the
expected i686 (and there's only one core), so presumably it's somewhere
close to our architecture baseline, either above or below.  The baseline
is -march=i686 since gcc-6_6.1.1-1 and stretch, according to the research
I did for <https://wiki.debian.org/ArchitectureSpecificsMemo>.

The /proc/cpuinfo would be useful information, since that includes a list
of capability flags.

cc gcc maintainers (in the absence of an i386 porter contact): Is there
a more formal/detailed specification for what CPU extensions we do and
don't intend to require on i386?

If this CPU is at or slightly above the baseline and mozjs78 is using
non-baseline instructions, then that's a bug in the mozjs78 source (most
likely the JIT) or the packaging. If this is the case, I suspect that our
upstream (Mozilla) will refuse to support older CPUs, so we will have to
choose between making non-upstreamable changes or declaring that mozjs78
violating the baseline is wontfix. Our i386 mozjs78 is already built in a
configuration that upstream don't support, because they assume SSE on i386,
but SSE isn't part of our baseline, so we are still using the legacy i387
FPU instructions and their weird extended-precision behaviour; some tests
fail and are skipped as a result.

If it's slightly below the baseline (only a few missing opcodes), then it
isn't a bug for packages to not work, but it's possible that you get away
with it most of the time because the missing opcodes are rarely emitted?

Does Firefox work on this machine?

Did older versions of GNOME Shell (buster or stretch) work on this machine?
If yes, do they have acceptable performance in practice?

> [  204.840919] traps: gnome-session-f[939] trap invalid opcode ip:b4e7f86a sp:bfcc1460 error:0 in librsvg-2.so.2.47.0[b4e6d000+5b7000]

If this is considered a mozjs78 bug, then librsvg has a similar bug
(possibly related to Rust, which they both use); or if your CPU is just
too old to run binaries compiled with Debian's post-stretch assumptions,
then the same applies to librsvg.

librsvg is likely to be more of a problem than mozjs78, because you can
take mozjs78 out of the critical path by using XFCE, LXDE or one of the
GNOME 2 forks like MATE and GNOME Flashback, but if this is a desktop
system you are still going to want to render SVGs.

    smcv

Message #17 received at 973414@bugs.debian.org (full text, mbox, reply):

From: Martin-Éric Racine <martin-eric.racine@iki.fi>

To: Simon McVittie <smcv@debian.org>

Cc: 973414@bugs.debian.org, debian-gcc@lists.debian.org

Subject: Re: Bug#973414: libmozjs-78-0: invalid opcodes in libmozjs when launching GDM3

Date: Fri, 30 Oct 2020 14:07:17 +0200

pe 30. lokak. 2020 klo 13.50 Simon McVittie (smcv@debian.org) kirjoitti:
> On Fri, 30 Oct 2020 at 10:35:21 +0200, Martin-Éric Racine wrote:
> > [  165.903916] traps: gnome-shell[869] trap invalid opcode ip:b5518f8a sp:b17d6d80 error:0 in libmozjs-78.so.78.3.0[b4b98000+98c000]
>
> Which specific x86 CPU is this? I see `uname -m` is i586 rather than the
> expected i686 (and there's only one core), so presumably it's somewhere
> close to our architecture baseline, either above or below.  The baseline
> is -march=i686 since gcc-6_6.1.1-1 and stretch, according to the research
> I did for <https://wiki.debian.org/ArchitectureSpecificsMemo>.

Geode LX800. This is technically a 686 but it doesn't support PAE, so
the CPU family remains 586.

> The /proc/cpuinfo would be useful information, since that includes a list
> of capability flags.

processor    : 0
vendor_id    : AuthenticAMD
cpu family    : 5
model        : 10
model name    : Geode(TM) Integrated Processor by AMD PCS
stepping    : 2
cpu MHz        : 498.025
cache size    : 128 KB
physical id    : 0
siblings    : 1
core id        : 0
cpu cores    : 1
apicid        : 0
initial apicid    : 0
fdiv_bug    : no
f00f_bug    : no
coma_bug    : no
fpu        : yes
fpu_exception    : yes
cpuid level    : 1
wp        : yes
flags        : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext
3dnowext 3dnow cpuid 3dnowprefetch vmmcall
bugs        : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
bogomips    : 996.05
clflush size    : 32
cache_alignment    : 32
address sizes    : 32 bits physical, 32 bits virtual
power management:

> cc gcc maintainers (in the absence of an i386 porter contact): Is there
> a more formal/detailed specification for what CPU extensions we do and
> don't intend to require on i386?

AFAIK plain 686 (without PAE) is the baseline. Debian's
linux-image-686 actually is configured for Geode.

> Does Firefox work on this machine?
>
> Did older versions of GNOME Shell (buster or stretch) work on this machine?
> If yes, do they have acceptable performance in practice?

Both have worked until whatever is currently in Stable. Firefox as-is,
gnome-shell using the X wrapper.

Martin-Éric

Message #22 received at 973414@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Martin-Éric Racine <martin-eric.racine@iki.fi>, 973414@bugs.debian.org

Cc: rustc@packages.debian.org

Subject: Re: Bug#973414: libmozjs-78-0: invalid opcodes in libmozjs when launching GDM3

Date: Sun, 8 Nov 2020 12:39:50 +0000

Control: retitle -1 libmozjs-78-0: invalid opcodes when launching GDM on AMD Geode
Control: tags -1 = help

On Fri, 30 Oct 2020 at 14:07:17 +0200, Martin-Éric Racine wrote:
> pe 30. lokak. 2020 klo 13.50 Simon McVittie (smcv@debian.org) kirjoitti:
> > On Fri, 30 Oct 2020 at 10:35:21 +0200, Martin-Éric Racine wrote:
> > > [  165.903916] traps: gnome-shell[869] trap invalid opcode ip:b5518f8a sp:b17d6d80 error:0 in libmozjs-78.so.78.3.0[b4b98000+98c000]
> >
> > Which specific x86 CPU is this?
> 
> Geode LX800. This is technically a 686 but it doesn't support PAE, so
> the CPU family remains 586.

> > The /proc/cpuinfo would be useful information, since that includes a list
> > of capability flags.
> flags        : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext
> 3dnowext 3dnow cpuid 3dnowprefetch vmmcall

Notably, this doesn't include SSE (any version), or various smaller
extensions like POPCNT.

My guess would be that there's a hidden SSE assumption somewhere
in mozjs. I'm fairly sure Mozilla upstream doesn't really support
non-SSE CPUs any more (several tests fail because we're using i387
rather than SSE for arithmetic), so any porting to older x86 CPUs would
be Debian-specific. The Debian GNOME team packages mozjs because we need
it for GNOME Shell and gjs, but we don't really have the knowledge or
resources to port it to (sub)architectures that don't meet upstream's
assumptions - any help you can provide would be appreciated.

Because your syslog also included similar crashes in librsvg, which is
unrelated to mozjs except that both involve Rust code, I wonder whether
it might be the rust compiler rather than mozjs' JIT that is emitting
non-i586 opcodes on x86?

    smcv

Message #31 received at 973414@bugs.debian.org (full text, mbox, reply):

From: Martin-Éric Racine <martin-eric.racine@iki.fi>

To: Simon McVittie <smcv@debian.org>

Cc: 973414@bugs.debian.org, rustc@packages.debian.org

Subject: Re: Bug#973414: libmozjs-78-0: invalid opcodes in libmozjs when launching GDM3

Date: Mon, 9 Nov 2020 20:05:01 +0200

su 8. marrask. 2020 klo 14.40 Simon McVittie (smcv@debian.org) kirjoitti:
> Because your syslog also included similar crashes in librsvg, which is
> unrelated to mozjs except that both involve Rust code, I wonder whether
> it might be the rust compiler rather than mozjs' JIT that is emitting
> non-i586 opcodes on x86?

Good observation. I'd really like to know this as well.

Worse comes, if it indeed turns out that libmozjs doesn't support
non-PAE hosts anymore, I could easily switch to lightdm or lxdm.
However, without librsvg, pretty much all display managers break,
since they all use the default SVG background configured by
desktop-base.

Martin-Éric

Message #36 received at 973414@bugs.debian.org (full text, mbox, reply):

From: Martin-Éric Racine <martin-eric.racine@iki.fi>

To: Simon McVittie <smcv@debian.org>

Cc: 973414@bugs.debian.org, rustc@packages.debian.org

Subject: Re: Bug#973414: libmozjs-78-0: invalid opcodes in libmozjs when launching GDM3

Date: Thu, 3 Dec 2020 22:55:40 +0200

ma 9. marrask. 2020 klo 20.05 Martin-Éric Racine
(martin-eric.racine@iki.fi) kirjoitti:
>
> su 8. marrask. 2020 klo 14.40 Simon McVittie (smcv@debian.org) kirjoitti:
> > Because your syslog also included similar crashes in librsvg, which is
> > unrelated to mozjs except that both involve Rust code, I wonder whether
> > it might be the rust compiler rather than mozjs' JIT that is emitting
> > non-i586 opcodes on x86?
>
> Good observation. I'd really like to know this as well.

Seems that something broke there a while back. See bug #891561.

Martin-Éric

Message #41 received at 973414@bugs.debian.org (full text, mbox, reply):

From: Martin-Éric Racine <martin-eric.racine@iki.fi>

To: Simon McVittie <smcv@debian.org>

Cc: 973414@bugs.debian.org, rustc@packages.debian.org

Subject: Re: Bug#973414: libmozjs-78-0: invalid opcodes in libmozjs when launching GDM3

Date: Tue, 8 Dec 2020 17:35:24 +0200

ma 9. marrask. 2020 klo 20.05 Martin-Éric Racine
(martin-eric.racine@iki.fi) kirjoitti:
>
> su 8. marrask. 2020 klo 14.40 Simon McVittie (smcv@debian.org) kirjoitti:
> > Because your syslog also included similar crashes in librsvg, which is
> > unrelated to mozjs except that both involve Rust code, I wonder whether
> > it might be the rust compiler rather than mozjs' JIT that is emitting
> > non-i586 opcodes on x86?
>
> Good observation. I'd really like to know this as well.
>
> Worse comes, if it indeed turns out that libmozjs doesn't support
> non-PAE hosts anymore, I could easily switch to lightdm or lxdm.
> However, without librsvg, pretty much all display managers break,
> since they all use the default SVG background configured by
> desktop-base.

Having downgraded and pinned all librsvg2 packages to what's in
oldstable (2.40.16) restores GDM's fallback to Xorg at least enough to
display gnome-session-failed. I suspect that the only bit of failure
that's left is because of mozjs, which unfortunately cannot be
downgraded, because it's a versioned dependency for a number of
packages. This would suggest that the problem indeed is with the Rust
compiler.

I'd really love to hear from Rust's maintainer at this point.

Martin-Éric

Message #46 received at 973414@bugs.debian.org (full text, mbox, reply):

From: Martin-Éric Racine <martin-eric.racine@iki.fi>

To: Simon McVittie <smcv@debian.org>

Cc: 973414@bugs.debian.org, rustc@packages.debian.org

Subject: Re: Bug#973414: libmozjs-78-0: invalid opcodes in libmozjs when launching GDM3

Date: Thu, 10 Dec 2020 18:29:39 +0200

ti 8. jouluk. 2020 klo 17.35 Martin-Éric Racine
(martin-eric.racine@iki.fi) kirjoitti:
>
> ma 9. marrask. 2020 klo 20.05 Martin-Éric Racine
> (martin-eric.racine@iki.fi) kirjoitti:
> >
> > su 8. marrask. 2020 klo 14.40 Simon McVittie (smcv@debian.org) kirjoitti:
> > > Because your syslog also included similar crashes in librsvg, which is
> > > unrelated to mozjs except that both involve Rust code, I wonder whether
> > > it might be the rust compiler rather than mozjs' JIT that is emitting
> > > non-i586 opcodes on x86?
> >
> > Good observation. I'd really like to know this as well.
> >
> > Worse comes, if it indeed turns out that libmozjs doesn't support
> > non-PAE hosts anymore, I could easily switch to lightdm or lxdm.
> > However, without librsvg, pretty much all display managers break,
> > since they all use the default SVG background configured by
> > desktop-base.
>
> Having downgraded and pinned all librsvg2 packages to what's in
> oldstable (2.40.16) restores GDM's fallback to Xorg at least enough to
> display gnome-session-failed. I suspect that the only bit of failure
> that's left is because of mozjs, which unfortunately cannot be
> downgraded, because it's a versioned dependency for a number of
> packages. This would suggest that the problem indeed is with the Rust
> compiler.
>
> I'd really love to hear from Rust's maintainer at this point.

Btw, when it comes to libmozjs, is there any attachment you'd need?
gdb backtrace, etc.?

Martin-Éric

Message #51 received at 973414@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Martin-Éric Racine <martin-eric.racine@iki.fi>, 973414@bugs.debian.org

Cc: rustc@packages.debian.org

Subject: Re: Bug#973414: libmozjs-78-0: invalid opcodes in libmozjs when launching GDM3

Date: Thu, 10 Dec 2020 17:47:46 +0000

On Thu, 10 Dec 2020 at 18:29:39 +0200, Martin-Éric Racine wrote:
> Btw, when it comes to libmozjs, is there any attachment you'd need?
> gdb backtrace, etc.?

A backtrace is always useful, and it would also be useful to know which
opcode not supported by your CPU it's trying to execute.

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.

    smcv

Message #56 received at 973414@bugs.debian.org (full text, mbox, reply):

From: Martin-Éric Racine <martin-eric.racine@iki.fi>

To: Simon McVittie <smcv@debian.org>

Cc: 973414@bugs.debian.org, rustc@packages.debian.org

Subject: Re: Bug#973414: libmozjs-78-0: invalid opcodes in libmozjs when launching GDM3

Date: Thu, 10 Dec 2020 20:02:42 +0200

to 10. jouluk. 2020 klo 19.47 Simon McVittie (smcv@debian.org) kirjoitti:
>
> On Thu, 10 Dec 2020 at 18:29:39 +0200, Martin-Éric Racine wrote:
> > Btw, when it comes to libmozjs, is there any attachment you'd need?
> > gdb backtrace, etc.?
>
> A backtrace is always useful, and it would also be useful to know which
> opcode not supported by your CPU it's trying to execute.

$ sudo coredumpctl debug 855 --output /tmp/coredump_gnome-shell
           PID: 855 (gnome-shell)
           UID: 101 (Debian-gdm)
           GID: 122 (Debian-gdm)
        Signal: 4 (ILL)
     Timestamp: Thu 2020-12-10 18:38:09 EET (1h 15min ago)
  Command Line: /usr/bin/gnome-shell
    Executable: /usr/bin/gnome-shell
 Control Group: /user.slice/user-101.slice/session-c2.scope
          Unit: session-c2.scope
         Slice: user-101.slice
       Session: c2
     Owner UID: 101 (Debian-gdm)
       Boot ID: b115ec37ecca4f75acd8d60bc6a44403
    Machine ID: 1063a9d1fb9df6e371ea9f94491345ed
      Hostname: geode
       Storage:
/var/lib/systemd/coredump/core.gnome-shell.101.b115ec37ecca4f75acd8d60bc6a44403.855.1607618289000000.zst
       Message: Process 855 (gnome-shell) of user 101 dumped core.

                Stack trace of thread 861:
                #0  0x00000000b5500d08
_ZN17compiler_builtins3int4udiv12__udivmoddi417h8768e341ea5a27afE
(libmozjs-78.so.0 + 0xa01d08)

GNU gdb (Debian 10.1-1+b1) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/gnome-shell...
(No debugging symbols found in /usr/bin/gnome-shell)
[New LWP 861]
[New LWP 855]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".

warning: Can't read data for section '.debug_info' in file
'/usr/lib/debug/.build-id/8e/1bdec525caa9d999e8d03f4e90d5e350bddf4f.debug'
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.
(gdb) c
The program is not being run.
(gdb)

> 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.

Martin-Éric

Message #61 received at 973414@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Martin-Éric Racine <martin-eric.racine@iki.fi>

Cc: 973414@bugs.debian.org, rustc@packages.debian.org, 976374@bugs.debian.org

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

Date: Thu, 10 Dec 2020 19:21:15 +0000

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

Message #82 received at 973414@bugs.debian.org (full text, mbox, reply):

From: Martin-Éric Racine <martin-eric.racine@iki.fi>

To: Simon McVittie <smcv@debian.org>

Cc: 973414@bugs.debian.org, rustc@packages.debian.org, 976374@bugs.debian.org

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

Date: Thu, 10 Dec 2020 21:43:18 +0200

to 10. jouluk. 2020 klo 21.21 Simon McVittie (smcv@debian.org) kirjoitti:
> 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 cannot help but wonder what platform defaults GCC uses on i386.
Given how the baseline kernel for i386 (linux-image-686 i.e. Linux for
older PCs) is configured for Geode LX, I would presume the GCC
defaults are aligned to match. AFAIK that kernel is compiled for Geode
and for Generic 686, which I presume means only using the flags that
intersect both CPU variants. It might be a good starting point for the
Rust compiler too.

> 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.

I was suspecting this discussion would take place sooner or later.
From this perspective, I wouldn't be surprised if Bullseye were the
last Debian release to support non-PAE 686.

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. Doubly so considering that
Debian is pretty much the last distro that installs on a Geode LX out
of the box.

Martin-Éric

Message #87 received at 973414@bugs.debian.org (full text, mbox, reply):

From: Martin-Éric Racine <martin-eric.racine@iki.fi>

To: Simon McVittie <smcv@debian.org>

Cc: 973414@bugs.debian.org, rustc@packages.debian.org, 976374@bugs.debian.org

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

Date: Thu, 10 Dec 2020 23:02:44 +0200

to 10. jouluk. 2020 klo 21.43 Martin-Éric Racine
(martin-eric.racine@iki.fi) kirjoitti:
>
> to 10. jouluk. 2020 klo 21.21 Simon McVittie (smcv@debian.org) kirjoitti:
> > 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 cannot help but wonder what platform defaults GCC uses on i386.
> Given how the baseline kernel for i386 (linux-image-686 i.e. Linux for
> older PCs) is configured for Geode LX, I would presume the GCC
> defaults are aligned to match. AFAIK that kernel is compiled for Geode
> and for Generic 686, which I presume means only using the flags that
> intersect both CPU variants. It might be a good starting point for the
> Rust compiler too.

I'm no expert on x86 instruction sets, but looking at GCC options
suggests that "i686" would be the same as -march=pentiumpro and
-mtune=generic, which seems to provide support for a broader range of
i686-family chips. It's just a guess (I know nothing of Rust's
building environment), but I wouldn't be surprised if the above patch
also affected -mtune, which is perhaps too tight of a CPU spec.

Again, checking what compiler and linker options are used to build
linux-image-686 might provide a clearer view of what instruction set
is a safe baseline for the i386 port.

Martin-Éric

Message #92 received at 973414@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Martin-Éric Racine <martin-eric.racine@iki.fi>

Cc: 973414@bugs.debian.org, rustc@packages.debian.org, 976374@bugs.debian.org

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

Date: Thu, 10 Dec 2020 21:12:43 +0000

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.

    smcv

Message #97 received at 973414@bugs.debian.org (full text, mbox, reply):

From: Martin-Éric Racine <martin-eric.racine@iki.fi>

To: Simon McVittie <smcv@debian.org>

Cc: 973414@bugs.debian.org, rustc@packages.debian.org, 976374@bugs.debian.org

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

Date: Sat, 20 Feb 2021 16:24:03 +0200

to 10. jouluk. 2020 klo 23.12 Simon McVittie (smcv@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

Message #102 received at 973414@bugs.debian.org (full text, mbox, reply):

From: Martin-Éric Racine <martin-eric.racine@iki.fi>

To: Simon McVittie <smcv@debian.org>

Cc: 973414@bugs.debian.org, rustc@packages.debian.org, 976374@bugs.debian.org

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

Date: Thu, 13 Oct 2022 09:15:25 +0300

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@iki.fi> wrote:
>
> to 10. jouluk. 2020 klo 23.12 Simon McVittie (smcv@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

Send a report that this bug log contains spam.