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
