On Tue, Sep 11, 2018 at 02:10:14PM +0900, Mike Hommey wrote: > On Tue, Sep 11, 2018 at 09:08:35AM +0900, Mike Hommey wrote: > > On Mon, Sep 10, 2018 at 08:40:08PM +0200, Moritz Mühlenhoff wrote: > > > On Mon, Sep 10, 2018 at 02:54:54AM +0200, b...@debian.16bits.net wrote: > > > > /proc/cpuinfo shows it supports sse, but not sse2. And movsd is a sse2 > > > > instruction [1] > > > > > > This is an intentional upstream change which also affects the binaries > > > provided by Mozilla: > > > https://support.mozilla.org/en-US/kb/your-hardware-no-longer-supported > > > > > > It might be possible to disable the use of SSE2 for the i386 architecture > > > (as every CPU covered by amd64 supports SSE2), but I have no idea how > > > intrusive that would be (and might cause some problems in the long term > > > if the non-SSE2 code paths are not covered by upstream CI/tests). It's > > > also one additional patch to be carried forward until i386 is retired > > > as an architecture. > > > > The problem from bug #877445 is actually trivial to fix, but the ones > > from bug 908449/908396 would seem unrelated. I tried running firefox-esr > > from stretch-security in qemu without sse2 (without kvm), and it... just > > worked. I couldn't even reproduce #877445. The problem is that > > apparently, even when doing emulation, qemu doesn't actually disable > > instruction sets, it just hides them from cpuid. > > So, looking at a local build for i386, it appears that most of the SSE2 > code in libxul comes from ... rust. Because the rust compiler happily > emits SSE2 on i386, which it shouldn't be doing.
Now that bug #908561 is fixed to address the rust problem, I created a build for stretch with a fix for bug #877445 and built against the fixed rust compiler. Could anyone with a non-SSE2 CPU check if it works (as per the above, qemu doesn't cut it)? https://people.debian.org/~glandium/firefox-esr_60.2.0esr-1~deb9u2.1_i386.deb sha256: b7cdb4b4ff57d302e4b5d2fbc3ff7a7bce2f35431e3fc40e0915dc2d65deefac Thanks Mike
