SIGILL due to movsd on Pentium III

andygoth · 06-21-2018, 12:16 PM

Running Slackware-current (updated Thu Jun 21 05:18:41 UTC 2018), experiencing multiple SIGILL crashes due to the movsd SSE2 instruction. My computer has a Pentium III and lacks SSE2.

I first encountered this with Firefox, as I reported here. But now that I hit it again when running "thunar /" (dies inside librsvg-2.so.2), I'm wondering if the problem isn't specifically Firefox but rather the way Slackware-current is being compiled.

What CPU does Slackware-current target? I believe it's advertised as i686, but that means anything Pentium Pro and up, which includes the Pentium III.

volkerdi · 06-21-2018, 12:39 PM

For userspace, we target i586 if possible, i686 otherwise. The problem is that there are a lot of things that only take this as a suggestion and compile using opcodes that didn't appear in the first i686 CPUs. I notice that both of the programs that are giving you problems (Firefox and librsvg) are now Rust-based, and I've also had some reports about things that are compiled with LLVM.

I'm not sure how feasible it would be to do anything about this issue, but would consider patches if any happen to turn up.

andygoth · 06-22-2018, 12:54 AM

Quote:

Originally Posted by volkerdi

For userspace, we target i586 if possible, i686 otherwise. The problem is that there are a lot of things that only take this as a suggestion and compile using opcodes that didn't appear in the first i686 CPUs.

"It seems that we are almost ready to require SSE2 for Mozilla-built Firefox for 32-bit x86 Linux. [...] Can we require SSE2 for Mozilla builds of Firefox for Linux? Yes, I am comfortable making that decision today. [...] I can tell you with 100% certainty that angry Debian users *will* come with patches and will return even angrier if patches are not even welcome. [...] I'm willing to accept the cost of a minority of angry users for an offsetting benefit. [...] [G]iven how hard it has been to find any machine at Mozilla that didn't have SSE2. (source)"

"As described in https://groups.google.com/forum/#!to...rm/v0QAe2olnH0 there is really no logical reason to use FF in a real non-SSE2 environment! (source)"

Not a lot of love from the Mozilla folks for non-SSE2 systems...

However, these aren't Mozilla-provided builds of Firefox we're talking about. These are your builds. I'm fine with Mozilla targeting whichever CPUs they choose. I draw the line when they change the builds scripts to take away your ability to choose different targets. But I needlessly escalate the situation by uncharitably picking the worst interpretation, so instead let's start with the much more plausible explanation you've already given: the Rust compiler assuming SSE2.

Here is outside corroboration:

"The 32-bit x86 Rust compiler also targets the 'i686' CPU architecture. Sortof. Rust doesn't actually work on these processors, despite claims, because it actually targets the Pentium 4 processor, by using SSE2 instructions that were first introduced on that chip. If you try to run it on a real i686 (a Pentium Pro, Pentium II, or Pentium III), it will try to execute SSE2 instructions which that chip knows nothing about, and crash. (source)"

Check out the rest of the above-linked blog post for potentially useful information on a path forward. I hope it succeeds in producing a Rust build that targets i586 or, at least, true i686 sans SSE2.

Update: I took a closer look, and it seems the article is more concerned about getting the Rust compiler to run on an i586 than to get it to target the i586. But maybe it's enough to toss in --target as well as --build to achieve both. Whatever, it's past midnight, I should go to bed.

volkerdi · 06-22-2018, 12:59 AM

Quote:

Originally Posted by andygoth

Not a lot of love from the Mozilla folks for non-SSE2 systems...

In 2018, don't expect a lot from us, either.

andygoth · 06-22-2018, 01:14 AM

Quote:

Originally Posted by volkerdi

In 2018, don't expect a lot from us, either.

Yeah, I understand that, but for this particular project I chose Slackware not only for my familiarity with it but also because I had believed it targeted the CPU. Otherwise I'd have sought some other distribution, rolled a Linux From Scratch installation, gotten an older version, whatever. Now that I have the system almost fully operational despite severe hardware handicaps, I'm interested in seeing how far it can go.

Plus, Firefox isn't really a hard requirement. I do plan to experiment with other browsers, such as Midori and Links and Chrome and Konqueror and MSIE+Wine (just kidding). Right now the system has only 192 megabytes of RAM since the upgrade stick I got is faulty, so I definitely want to go with lightweight options!

Darth Vader · 06-22-2018, 02:10 AM

Seriously? Did you really want to run that Firefox memory hog within 192MB of RAM?

Just for your fun, I looked right now, and Firefox and its 4 Web minions eat a whooping 2GB RAM.

And that's a really decent memory consumption thought, because in a "heavy" browsing session, I reached even 25GB. Do the math.

Petri Kaukasoina · 06-22-2018, 02:33 AM

Quote:

Originally Posted by andygoth

Firefox isn't really a hard requirement.

Rust became a requirement with Firefox 54. You might want to try 52.8.1esr: https://mirrors.slackware.com/slackw..._slack14.2.txz

andygoth · 06-22-2018, 09:17 AM

Quote:

Originally Posted by Darth Vader

Seriously? Did you really want to run that Firefox memory hog within 192MB of RAM?

Just for your fun, I looked right now, and Firefox and its 4 Web minions eat a whooping 2GB RAM.

And that's a really decent memory consumption thought, because in a "heavy" browsing session, I reached even 25GB. Do the math.

The 192 megabyte thing is hopefully just temporary until I can find compatible expansion RAM that isn't factory-fried. Also, I did succeed just fine in running Firefox with this amount of RAM in my previous Slackware 13 installation on this same computer. This computer isn't intended for heavy use anyhow. Plus, as I said before, the browser doesn't even need to be Firefox. That's just what I tried to use first because it had worked in Slackware 13, then when I got hit with the SIGILL, I immediately got to work tracking down the reason for that issue, which has nothing to do with RAM and rather everything to do with Rust assuming SSE2.

Quote:

Originally Posted by Petri Kaukasoina

Rust became a requirement with Firefox 54. You might want to try 52.8.1esr: https://mirrors.slackware.com/slackw..._slack14.2.txz

I'll give it a shot, thanks! But I will also be looking into compiling Rust to actually target i586, then using that to build Firefox and librsvg for Thunar. Of course, I won't be using the now-192 megabyte machine to actually run the compiler. ;^)

the3dfxdude · 06-22-2018, 12:15 PM

I think what I am seeing is that i686 in practice is being used mostly on AMD64 (x86-64) class machines or newer, probably in multi-lib under 64-bit kernel. I think all of these machines have SSE2. So think of i686 packages as 32-bit application mode of AMD64 machines, since that's all the devs have.

Someday I think we will see a situation that 32-bit OS breaks even on baseline i686 machines, because of something like this and no-one was looking. Similar things have happened before. I speak this as I am still running 32-bit OS on my EEE PC 1000, and spending money right now to fully max out it's capabilities, since it such a nice machine. Slackware 14.2 still flies on it. I run lynx about 50% time on it, because I'm starting to hate HTML5 and CSS crap getting in the way, and seamonkey if I feel like it. Granted, it does have SSE2+. So not bad for an atom. But I think something will eventually cause me a problem.

But even in 64-bit land, things aren't exactly pretty. I was trying to run a game for the kids on their machine, and per spec said it would run, but found that it actually required SSE3, which it didn't have, and gave me "Illegal Instruction". Strange because there is a really good chance it would have run fine otherwise.

aaazen · 06-22-2018, 02:00 PM

It seems to me that using the --march CFLAGS could help this situation.

The mozilla-firefox.SlackBuild script has this where
the SLKCFLAGS are not set:

Code:

if [ "$ARCH" = "i586" ]; then
  SLKCFLAGS=""
  LIBDIRSUFFIX=""
  OPTIMIZE=${OPTIMIZE:-"-O1"}
elif [ "$ARCH" = "i686" ]; then
  SLKCFLAGS=""
  LIBDIRSUFFIX=""
  OPTIMIZE=${OPTIMIZE:-"-O1"}

How about changing it the following?

Code:

if [ "$ARCH" = "i586" ]; then
  SLKCFLAGS="-march=i586 -mtune=i686"
  LIBDIRSUFFIX=""
  OPTIMIZE=${OPTIMIZE:-"-O1"}
elif [ "$ARCH" = "i686" ]; then
  SLKCFLAGS="-march=i686 -mtune=i686"
  LIBDIRSUFFIX=""
  OPTIMIZE=${OPTIMIZE:-"-O1"}

Update: I tested this on an old Athlon K7 and it does not work.... Seamonkey also appears to have this bug.

andygoth · 06-22-2018, 09:20 PM

Quote:

Originally Posted by aaazen

It seems to me that using the --march CFLAGS could help this situation.

That looks worthwhile to me, but I'm more concerned about Rust than C, namely getting Rust to stop emitting SSE2 instructions. Extrapolating from this article, I think the way to do this is to pass the --target=i586-pc-linux-gnu option to rustc. There's supposed to be a RUSTFLAGS variable for that purpose. But then again, see here. Apparently, RUSTFLAGS isn't honored if --target is explicitly used on the command line.

Update: Okay, I tried building, incorporating your changes plus adding --target=i586-pc-linux-gnu to RUSTFLAGS. This resulted in the following failure:

Code:

 9:25.90 libpsshparser.a.desc
 9:26.26 force-cargo-library-build
 9:27.78 error: failed to run `rustc` to learn about target-specific information
 9:27.78 
 9:27.78 Caused by:
 9:27.78   process didn't exit successfully: `/usr/bin/rustc - --crate-name ___ --print=file-names -C opt-level=2 -C debuginfo=2 -Cdebuginfo=0 --target=i586-pc-linux-gnu --target i686-unknown-linux-gnu --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro` (exit code: 101)
 9:27.78 --- stderr
 9:27.78 error: Option 'target' given more than once
 9:27.78 
 9:27.78 
 9:27.78 gmake[4]: *** [/tmp/firefox-60.0.2/config/rules.mk:972: force-cargo-library-build] Error 101
 9:27.78 gmake[3]: *** [/tmp/firefox-60.0.2/config/recurse.mk:73: toolkit/library/rust/target] Error 2
 9:27.79 gmake[3]: *** Waiting for unfinished jobs....

Clearly, the Firefox build scripts are adding "--target i686-unknown-linux-gnu" somewhere. I'll have to track that down later.

Also, this quasi-contradicts the report I found earlier about RUSTFLAGS not being honored when --target is being used. To resolve the contradiction, I'm going to guess rustc itself doesn't ever looking at RUSTFLAGS, similar to how gcc doesn't look at CFLAGS, and it's the build system that's tacking RUSTFLAGS onto the command line. Either the build system used by Firefox isn't the same as was in the report, which I can't be bothered to read again right now, or Firefox's build scripts are stuffing a second --target in the same RUSTFLAGS variable before it's flowing down to the underlying build system.

aaazen · 06-23-2018, 12:58 PM

I failed to fix the problem using -march...

But did discover that Slackware 14.2 firefox works fine on an old Athlon K7 and the build script in patches/ has no -march options set.

The K7 does not have sse or sse2.

Code:

#cat /proc/cupinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 2
model name      : AMD Athlon(tm) Processor
stepping        : 1
cpu MHz         : 700.081
cache size      : 512 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 vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow 3dnowprefetch rsb_ctxsw retpoline vmmcall
bugs            : fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2
bogomips        : 1400.16
clflush size    : 32
cache_alignment : 32
address sizes   : 36 bits physical, 32 bits virtual
power management:

andygoth · 06-23-2018, 01:19 PM

Quote:

Originally Posted by aaazen

I failed to fix the problem using -march...

But did discover that Slackware 14.2 firefox works fine on an old Athlon K7 and the build script in patches/ has no -march options set.

The K7 does not have sse or sse2.

Can you run uname -a? Perhaps the architecture isn't one of the following:

i386 i486 i686 i768 x86

Yes, I really mean i768. More on that later.

Anyway, I tried building Firefox myself, but it failed after a little over two hours due to disk space. I'll allocate more space and try again. What a pain.

Here's my patch so far:

Code:

root@darkstar:~/mozilla-firefox# zcat firefox.i586.diff.gz
diff -Nur firefox-60.0.2.orig/servo/python/servo/util.py firefox-60.0.2/servo/python/servo/util.py
--- firefox-60.0.2.orig/servo/python/servo/util.py	2018-06-05 14:47:34.000000000 -0500
+++ firefox-60.0.2/servo/python/servo/util.py	2018-06-23 11:23:42.962000000 -0500
@@ -70,7 +70,7 @@
     os_type = host_platform()
     cpu_type = platform.machine().lower()
     if cpu_type in ["i386", "i486", "i686", "i768", "x86"]:
-        cpu_type = "i686"
+        cpu_type = "i586"
     elif cpu_type in ["x86_64", "x86-64", "x64", "amd64"]:
         cpu_type = "x86_64"
     elif cpu_type == "arm":

Code:

root@darkstar:~/mozilla-firefox# diff -u ../mozilla-firefox~/mozilla-firefox.SlackBuild mozilla-firefox.SlackBuild
--- ../mozilla-firefox~/mozilla-firefox.SlackBuild	2018-05-11 13:29:39.094089587 -0500
+++ mozilla-firefox.SlackBuild	2018-06-23 11:36:19.556000000 -0500
@@ -45,7 +45,7 @@
 # Automatically determine the architecture we're building on:
 if [ -z "$ARCH" ]; then
   case "$( uname -m )" in
-    i?86) export ARCH=i686 ;;
+    i?86) export ARCH=i586 ;;
     arm*) export ARCH=arm ;;
     # Unless $ARCH is already set, use uname -m for all other archs:
        *) export ARCH=$( uname -m ) ;;
@@ -67,16 +67,16 @@
 # Firefox has been requiring more and more memory, especially while linking
 # libxul. If it fails to build natively on x86 32-bit, it can be useful to
 # attempt the build using an x86_64 kernel and a 32-bit userspace. Detect this
-# situation and set the ARCH to i686. Later in the script we'll add some
+# situation and set the ARCH to i586. Later in the script we'll add some
 # options to the .mozconfig so that the compile will do the riight thing.
 if [ "$(uname -m)" = "x86_64" -a "$(file -L /usr/bin/gcc | grep 80386 | grep 32-bit)" != "" ]; then
   COMPILE_X86_UNDER_X86_64=true
-  ARCH=i686
+  ARCH=i586
   # Also use the gold linker for this:
   PATH="$(pwd)/gold:$PATH"
   export CC=${CC:-"gcc -B$(pwd)/gold"}
   export CXX=${CXX:-"g++ -B$(pwd)/gold"}
-elif [ "$ARCH" = "i686" ]; then
+elif [ "$ARCH" = "i586" ]; then
   # This might also help with the linker memory situation on some $ARCH. Feel free
   # to match any other $ARCH that could benefit from this.
   SLKLDFLAGS=" -Wl,--as-needed -Wl,--reduce-memory-overheads -Wl,--no-keep-memory -Wl,--stats"
@@ -122,7 +122,7 @@
 PGO=${PGO:-no}
 
 if [ "$ARCH" = "i586" ]; then
-  SLKCFLAGS=""
+  SLKCFLAGS="-march=i586 -mtune=i686"
   LIBDIRSUFFIX=""
   OPTIMIZE=${OPTIMIZE:-"-O1"}
 elif [ "$ARCH" = "i686" ]; then
@@ -197,6 +197,10 @@
 # Retain GTK+ v2 scrolling behavior:
 zcat $CWD/ff.ui.scrollToClick.diff.gz | patch -p1 --verbose || exit 1
 
+# Declare the machine type to be i586 even on i686 to avoid rustc emitting SSE2
+# instructions even though baseline i686 does not have them:
+zcat $CWD/firefox.i586.diff.gz | patch -p1 --verbose || exit 1
+
 # Fetch localization, if requested
 # https://bugzilla.mozilla.org/show_bug.cgi?id=1256955
 if [ ! -z $MOZLOCALIZE ]; then
@@ -285,9 +289,9 @@
 echo "ac_add_options --enable-optimize=\"${OPTIMIZE}\"" >> .mozconfig
 
 if [ "$COMPILE_X86_UNDER_X86_64" = "true" ]; then
-  # Compile for i686 under an x86_64 kernel:
-  echo "ac_add_options --host=i686-pc-linux-gnu" >> .mozconfig
-  echo "ac_add_options --target=i686-pc-linux-gnu" >> .mozconfig
+  # Compile for i586 under an x86_64 kernel:
+  echo "ac_add_options --host=i586-pc-linux-gnu" >> .mozconfig
+  echo "ac_add_options --target=i586-pc-linux-gnu" >> .mozconfig
 fi
 
 # Add the $OPTIONS above to .mozconfig:

I'm building on a 32-bit Slackware virtual machine. Later I'll have to try building on Slackware64 targeting 32-bit.

Since rustc seems to be the trouble, it's quite possible that it's unnecessary to set -march=i586 when $ARCH is i586. When I retry, first I'll back that change out.

Also, even if everything else is good, my patch to util.py might fail to apply in the future if the developers ever act on my "i768" bug report I just filed.

andygoth · 06-23-2018, 03:59 PM

Code:

105:32.39 /usr/bin/ld.gold: fatal error: libxul.so: mmap: failed to allocate 1301245352 bytes for output file: Cannot allocate memory

There is no RAM, only XUL.

I allotted this virtual machine 4 gigabytes of RAM, plus another 4 gigabytes swap. Doesn't make sense to give more than that to a 32-bit machine. Here, see this comment from mozilla-firefox.SlackBuild:

Code:

# Firefox has been requiring more and more memory, especially while linking
# libxul. If it fails to build natively on x86 32-bit, it can be useful to
# attempt the build using an x86_64 kernel and a 32-bit userspace. Detect this
# situation and set the ARCH to i686. Later in the script we'll add some
# options to the .mozconfig so that the compile will do the riight thing.

So, looks like a 64-bit machine is now required to build Firefox! Gonna have to try this all over again...

aaazen · 06-23-2018, 07:24 PM

Quote:

Originally Posted by andygoth

Can you run uname -a? Perhaps the architecture isn't one of the following:

i386 i486 i686 i768 x86

Yes, I really mean i768. More on that later.

Anyway, I tried building Firefox myself, but it failed after a little over two hours due to disk space. I'll allocate more space and try again. What a pain.

Here's my patch so far:

Code:

root@darkstar:~/mozilla-firefox# zcat firefox.i586.diff.gz
diff -Nur firefox-60.0.2.orig/servo/python/servo/util.py firefox-60.0.2/servo/python/servo/util.py
--- firefox-60.0.2.orig/servo/python/servo/util.py	2018-06-05 14:47:34.000000000 -0500
+++ firefox-60.0.2/servo/python/servo/util.py	2018-06-23 11:23:42.962000000 -0500
@@ -70,7 +70,7 @@
     os_type = host_platform()
     cpu_type = platform.machine().lower()
     if cpu_type in ["i386", "i486", "i686", "i768", "x86"]:
-        cpu_type = "i686"
+        cpu_type = "i586"
     elif cpu_type in ["x86_64", "x86-64", "x64", "amd64"]:
         cpu_type = "x86_64"
     elif cpu_type == "arm":

Code:

root@darkstar:~/mozilla-firefox# diff -u ../mozilla-firefox~/mozilla-firefox.SlackBuild mozilla-firefox.SlackBuild
--- ../mozilla-firefox~/mozilla-firefox.SlackBuild	2018-05-11 13:29:39.094089587 -0500
+++ mozilla-firefox.SlackBuild	2018-06-23 11:36:19.556000000 -0500
@@ -45,7 +45,7 @@
 # Automatically determine the architecture we're building on:
 if [ -z "$ARCH" ]; then
   case "$( uname -m )" in
-    i?86) export ARCH=i686 ;;
+    i?86) export ARCH=i586 ;;
     arm*) export ARCH=arm ;;
     # Unless $ARCH is already set, use uname -m for all other archs:
        *) export ARCH=$( uname -m ) ;;
@@ -67,16 +67,16 @@
 # Firefox has been requiring more and more memory, especially while linking
 # libxul. If it fails to build natively on x86 32-bit, it can be useful to
 # attempt the build using an x86_64 kernel and a 32-bit userspace. Detect this
-# situation and set the ARCH to i686. Later in the script we'll add some
+# situation and set the ARCH to i586. Later in the script we'll add some
 # options to the .mozconfig so that the compile will do the riight thing.
 if [ "$(uname -m)" = "x86_64" -a "$(file -L /usr/bin/gcc | grep 80386 | grep 32-bit)" != "" ]; then
   COMPILE_X86_UNDER_X86_64=true
-  ARCH=i686
+  ARCH=i586
   # Also use the gold linker for this:
   PATH="$(pwd)/gold:$PATH"
   export CC=${CC:-"gcc -B$(pwd)/gold"}
   export CXX=${CXX:-"g++ -B$(pwd)/gold"}
-elif [ "$ARCH" = "i686" ]; then
+elif [ "$ARCH" = "i586" ]; then
   # This might also help with the linker memory situation on some $ARCH. Feel free
   # to match any other $ARCH that could benefit from this.
   SLKLDFLAGS=" -Wl,--as-needed -Wl,--reduce-memory-overheads -Wl,--no-keep-memory -Wl,--stats"
@@ -122,7 +122,7 @@
 PGO=${PGO:-no}
 
 if [ "$ARCH" = "i586" ]; then
-  SLKCFLAGS=""
+  SLKCFLAGS="-march=i586 -mtune=i686"
   LIBDIRSUFFIX=""
   OPTIMIZE=${OPTIMIZE:-"-O1"}
 elif [ "$ARCH" = "i686" ]; then
@@ -197,6 +197,10 @@
 # Retain GTK+ v2 scrolling behavior:
 zcat $CWD/ff.ui.scrollToClick.diff.gz | patch -p1 --verbose || exit 1
 
+# Declare the machine type to be i586 even on i686 to avoid rustc emitting SSE2
+# instructions even though baseline i686 does not have them:
+zcat $CWD/firefox.i586.diff.gz | patch -p1 --verbose || exit 1
+
 # Fetch localization, if requested
 # https://bugzilla.mozilla.org/show_bug.cgi?id=1256955
 if [ ! -z $MOZLOCALIZE ]; then
@@ -285,9 +289,9 @@
 echo "ac_add_options --enable-optimize=\"${OPTIMIZE}\"" >> .mozconfig
 
 if [ "$COMPILE_X86_UNDER_X86_64" = "true" ]; then
-  # Compile for i686 under an x86_64 kernel:
-  echo "ac_add_options --host=i686-pc-linux-gnu" >> .mozconfig
-  echo "ac_add_options --target=i686-pc-linux-gnu" >> .mozconfig
+  # Compile for i586 under an x86_64 kernel:
+  echo "ac_add_options --host=i586-pc-linux-gnu" >> .mozconfig
+  echo "ac_add_options --target=i586-pc-linux-gnu" >> .mozconfig
 fi
 
 # Add the $OPTIONS above to .mozconfig:

I'm building on a 32-bit Slackware virtual machine. Later I'll have to try building on Slackware64 targeting 32-bit.

Since rustc seems to be the trouble, it's quite possible that it's unnecessary to set -march=i586 when $ARCH is i586. When I retry, first I'll back that change out.

Also, even if everything else is good, my patch to util.py might fail to apply in the future if the developers ever act on my "i768" bug report I just filed.

My target architecture AMD K7 says i686 and so does my build architecture.

I'm building on a quad core 64-bit machine with 6GB of ram and Slackware-current 32-bit installed. It does seem to build.

I tried building with the patches but still get "Illegal instruction" when I start firefox. The package does now say "i586" though.

I think the build script should try and follow the instructions in the Rust on 586 blog more closely since apparently it works.

In particular it needs:

Code:

export CFLAGS="-march=pentium"; export CXXFLAGS="-march=pentium"

Update: The CFLAGS and CXXFLAGS are for the rust.SlackBuild and this brings up a good question:
What is the oldest Intel/AMD processor that Slackware Current will support?