On Thu, Jun 27, 2019 at 03:26:32PM +0300, Adrian Bunk wrote:
> > We like to support non-sse2 on i386, but we are not comfortable
> > fixing webkit2gtk at this stage of the release.
>
> Why is this relatively small change a problem in a package where new
> upstream versions are permitted after the release of stable?
I'll try to explain again with more detail so we all understand the
nature of the proposed changes.
- WebKitGTK has several mechanisms to run JavaScript code, in brief: a
C-based interpreter (CLoop), an assembler-based interpreter and a
JIT compiler.
- CLoop is the slowest but it is portable and runs in all platforms.
It's the one selected at build time when the CPU is unsupported or
unknown.
- The other two generate CPU-specific code. In an effort to simplify
them upstream took recently the decision to stop supporting i386
processors without SSE2 instructions.
- Because of that, WebKitGTK 2.24.1 added a build-time check to detect
if the compiler can generate SSE2 instructions. For the Debian case
I had to add -msse2 -mfpmath=sse to CFLAGS, as suggested by
upstream.
- The consequence of this is that GCC generates SSE2 instructions when
appropriate when compiling regular C/C++ code, causing crashes like
the one previously reported.
- However, and this is the part that I originally overlooked, only the
C-based interpreter is working at the moment in i386. The other two
are less actively maintained for i386, and stopped working after
some big changes upstream in the last few months.
- So it is possible to remove the compile-time check for SSE2 and
build the package without those flags in i386.
What this all means is that the only real difference between
webkit2gtk 2.24.2-1 (in buster) and 2.24.2-2 (in sid) is that, for
i386, the former is compiled with -msse2 -mfpmath=sse and the latter
is not. So for floating point operations the former uses SSE2 and the
latter uses x87. This produces some differences in rounding in some
corner cases which could have user-visible consequences.
We don't know when it is going to happen, but once upstream brings
back JIT support to i386 again we would have to make the decision to
either:
a) keep using CLoop in order to remain compatible with non-SSE2 CPUs
(conservative approach, I'd probably support this one).
b) think of a way to support both sets of users so those with more
modern processors can benefit from the additional performance of
the JIT compiler. This could involve using e.g. /usr/lib/sse2/ for
those binaries.
I hope this clarifies the situation.
Berto
