Re: Bug#1017961: mozjs102: Fails to build on armel
Le mer. 31 août 2022 à 03:55, Wookey a écrit : > On 2022-08-25 11:34 +0100, Simon McVittie wrote: > > On Tue, 23 Aug 2022 at 21:42:29 +0100, Simon McVittie wrote: > > > > I don't have a good picture of where this puts us on a scale from "it's > > basically fine" to "armel users will report grave bugs in gjs-based > > packages whenever they try to run them, because they're hopelessly > > crashy". Does anyone have a better idea of whether these test failures > > are ignorable or RC? > > Not really. I don't know much about how mozjs, not exactly what the test > suite is testing. > > > I'm doing all this remotely on a porterbox, because my only armel > > machine was de-supported in Debian 11 due to kernel size issues and > > is headless anyway, > > I have some 32-bt armv7 hardware that can run a desktop so I'll fire > those up and test this on there to see if it's obviously broken or > not. > > I did try to get some feedback on whether armel should continue as a > release architecture at my debconf talk this year but no opinion was > expressed. I have no idea how many people would be affected but it's > certainly true that upstreams are not that bothered about continuing > to make things work on v5 so debian ends up noticing and fixing > things. We could certainly save ourselves some work by relegating it > to ports. We used isa-support's packages to get nodejs to run on a subset of armel, by depending on armv6-support and vfpv2-support. (actually nodejs needs armv6k, so armv6k-support is also on its way, available in isa-support 12). Maybe mozjs102 could try the same approach here ? Or maybe a better approach would be for "armel" architecture to upgrade to armv6k, if that makes sense. Jérémy
Re: Bug#1017961: mozjs102: Fails to build on armel
On 2022-08-25 11:34 +0100, Simon McVittie wrote: > On Tue, 23 Aug 2022 at 21:42:29 +0100, Simon McVittie wrote: > > I don't have a good picture of where this puts us on a scale from "it's > basically fine" to "armel users will report grave bugs in gjs-based > packages whenever they try to run them, because they're hopelessly > crashy". Does anyone have a better idea of whether these test failures > are ignorable or RC? Not really. I don't know much about how mozjs, not exactly what the test suite is testing. > I'm doing all this remotely on a porterbox, because my only armel > machine was de-supported in Debian 11 due to kernel size issues and > is headless anyway, I have some 32-bt armv7 hardware that can run a desktop so I'll fire those up and test this on there to see if it's obviously broken or not. I did try to get some feedback on whether armel should continue as a release architecture at my debconf talk this year but no opinion was expressed. I have no idea how many people would be affected but it's certainly true that upstreams are not that bothered about continuing to make things work on v5 so debian ends up noticing and fixing things. We could certainly save ourselves some work by relegating it to ports. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Bug#1017961: mozjs102: Fails to build on armel
On Tue, 23 Aug 2022 at 21:42:29 +0100, Simon McVittie wrote: > Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1786619 Upstream suggested that I should also turn off the JIT (see patch attached to the upstream bug), but that doesn't seem to have helped with the test failures. The test suite is segfaulting in most tests in the Atomics/*/bigint family: ## test262/built-ins/Atomics/xor/bigint/good-views.js: rc = -11, run time = 0.030321 TEST-UNEXPECTED-FAIL | test262/built-ins/Atomics/xor/bigint/good-views.js | (args: "") [0.0 s] ## test262/built-ins/Atomics/xor/bigint/non-shared-bufferdata.js: rc = -11, run time = 0.038158 TEST-UNEXPECTED-FAIL | test262/built-ins/Atomics/xor/bigint/non-shared-bufferdata.js | (args: "") [0.0 s] ## test262/built-ins/Atomics/or/bigint/good-views.js: rc = -11, run time = 0.038281 (etc.) and there is also a non-segfault test failure: ## test262/built-ins/Atomics/compareExchange/good-views.js: rc = 3, run time = 0.03819 /home/smcv/mozjs-armel/js/src/tests/test262/built-ins/Atomics/shell.js:188:7 uncaught exception: Test262Error: The value of view[3] is 0 Expected SameValue(«-5», «0») to be true (Testing with Int16Array.) Stack: testWithTypedArrayConstructors@/home/smcv/mozjs-armel/js/src/tests/test262/built-ins/Atomics/shell.js:188:7 @/home/smcv/mozjs-armel/js/src/tests/test262/built-ins/Atomics/compareExchange/good-views.js:16:31 TEST-UNEXPECTED-FAIL | test262/built-ins/Atomics/compareExchange/good-views.js | (args: "") [0.0 s] I don't have a good picture of where this puts us on a scale from "it's basically fine" to "armel users will report grave bugs in gjs-based packages whenever they try to run them, because they're hopelessly crashy". Does anyone have a better idea of whether these test failures are ignorable or RC? I don't want to end up in a situation where the GNOME team is responsible for fixing atomic ops that we don't understand, on machines that can't run GNOME and are unsupported by upstream, under the threat of having GNOME removed from Debian if we can't. I'm doing all this remotely on a porterbox, because my only armel machine was de-supported in Debian 11 due to kernel size issues and is headless anyway, so I can't run practical gjs apps on armel myself (and in any case it would take hours if not days to compile mozjs on actually-armel hardware). As another possible route, I've opened a release team bug inquiring about architecture-specific removals of gjs and rdeps from armel (#1018076). smcv
Re: Bug#1017961: mozjs102: Fails to build on armel
Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1786619
On Tue, 23 Aug 2022 at 13:31:21 +0100, Simon McVittie wrote:
> I tried the attached patch
Sorry, now attached.
> The next thing I'm going to try is using gcc 11 on armel as a workaround
> for #1017979.
That worked, but a lot of tests fail, probably as a result of the attached
patch being wrong. But perhaps it's enough to point someone in the right
direction?
smcv
From: Simon McVittie
Date: Tue, 23 Aug 2022 09:21:30 +0100
Subject: jit: Only use ARMv7 atomic operations on ARMv7 or higher
Debian's armel (ARM EABI softfloat) port has a lower baseline than the
armhf (ARM EABI hardfloat), currently ARMv5, so we need to fall back
to the "feeling lucky" atomics on this architecture.
Bug-Debian: https://bugs.debian.org/1017961
Signed-off-by: Simon McVittie
---
js/src/jit/GenerateAtomicOperations.py | 23 +-
.../shared/AtomicOperations-feeling-lucky-gcc.h| 5 -
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/js/src/jit/GenerateAtomicOperations.py b/js/src/jit/GenerateAtomicOperations.py
index d8a38a0..1cc1bf6 100644
--- a/js/src/jit/GenerateAtomicOperations.py
+++ b/js/src/jit/GenerateAtomicOperations.py
@@ -12,6 +12,11 @@ is_64bit = "JS_64BIT" in buildconfig.defines
cpu_arch = buildconfig.substs["CPU_ARCH"]
is_gcc = buildconfig.substs["CC_TYPE"] == "gcc"
+if cpu_arch == "arm":
+armv7 = (int(buildconfig.substs["ARM_ARCH"]) >= 7)
+else:
+armv7 = False
+
def fmt_insn(s):
return '"' + s + '\\n\\t"\n'
@@ -32,7 +37,7 @@ def gen_seqcst(fun_name):
}""" % {
"fun_name": fun_name,
}
-if cpu_arch == "arm":
+if cpu_arch == "arm" and armv7:
return r"""
INLINE_ATTR void %(fun_name)s() {
asm volatile ("dmb sy\n\t" ::: "memory");
@@ -104,7 +109,7 @@ def gen_load(fun_name, cpp_type, size, barrier):
"fun_name": fun_name,
"insns": insns,
}
-if cpu_arch == "arm":
+if cpu_arch == "arm" and armv7:
insns = ""
if barrier:
insns += fmt_insn("dmb sy")
@@ -191,7 +196,7 @@ def gen_store(fun_name, cpp_type, size, barrier):
"fun_name": fun_name,
"insns": insns,
}
-if cpu_arch == "arm":
+if cpu_arch == "arm" and armv7:
insns = ""
if barrier:
insns += fmt_insn("dmb sy")
@@ -280,7 +285,7 @@ def gen_exchange(fun_name, cpp_type, size):
"fun_name": fun_name,
"insns": insns,
}
-if cpu_arch == "arm":
+if cpu_arch == "arm" and armv7:
insns = ""
insns += fmt_insn("dmb sy")
insns += fmt_insn("0:")
@@ -336,7 +341,7 @@ def gen_cmpxchg(fun_name, cpp_type, size):
"cpp_type": cpp_type,
"fun_name": fun_name,
}
-if cpu_arch == "arm" and size == 64:
+if cpu_arch == "arm" and size == 64 and armv7:
return r"""
INLINE_ATTR %(cpp_type)s %(fun_name)s(%(cpp_type)s* addr,
%(cpp_type)s oldval,
@@ -440,7 +445,7 @@ def gen_cmpxchg(fun_name, cpp_type, size):
"fun_name": fun_name,
"insns": insns,
}
-if cpu_arch == "arm":
+if cpu_arch == "arm" and armv7:
insns = ""
insns += fmt_insn("dmb sy")
insns += fmt_insn("0:")
@@ -595,7 +600,7 @@ def gen_fetchop(fun_name, cpp_type, size, op):
"fun_name": fun_name,
"insns": insns,
}
-if cpu_arch == "arm":
+if cpu_arch == "arm" and armv7:
insns = ""
insns += fmt_insn("dmb sy")
insns += fmt_insn("0:")
@@ -664,7 +669,7 @@ def gen_copy(fun_name, cpp_type, size, unroll, direction):
assert size == 8
insns += fmt_insn("ldr %x[scratch], [%x[src], OFFSET]")
insns += fmt_insn("str %x[scratch], [%x[dst], OFFSET]")
-elif cpu_arch == "arm":
+elif cpu_arch == "arm" and armv7:
if size == 1:
insns += fmt_insn("ldrb %[scratch], [%[src], #OFFSET]")
insns += fmt_insn("strb %[scratch], [%[dst], #OFFSET]")
@@ -721,7 +726,7 @@ namespace jit {
def generate_atomics_header(c_out):
contents = ""
-if cpu_arch in ("x86", "x86_64", "arm", "aarch64"):
+if cpu_arch in ("x86", "x86_64", "aarch64") or armv7:
contents += "#define JS_HAVE_GENERATED_ATOMIC_OPS 1"
# `fence` performs a full memory barrier.
diff --git a/js/src/jit/shared/AtomicOperations-feeling-lucky-gcc.h b/js/src/jit/shared/AtomicOperations-feeling-lucky-gcc.h
index 2e38433..3954202 100644
--- a/js/src/jit/shared/AtomicOperations-feeling-lucky-gcc.h
+++ b/js/src/jit/shared/AtomicOperations-feeling-lucky-gcc.h
@@ -31,7 +31,10 @@
// Explicitly exclude tier-1 platforms.
#if (defined(__x86_64__) || defined(_M_X64) || defined(__i386__) || \
-
Re: Bug#1017961: mozjs102: Fails to build on armel
On Tue, 23 Aug 2022 at 10:07:47 +0100, Simon McVittie wrote:
> On Mon, 22 Aug 2022 at 20:25:17 -0400, Jeremy Bicha wrote:
> > I did notice this repeatedly in the build log:
> >
> > {standard input}: Assembler messages:
> > {standard input}: Error: selected processor does not support `dmb sy'
> > in ARM mode
> > {standard input}: Error: selected processor does not support `ldrexb
> > r0,[r1]' in ARM mode
> > {standard input}: Error: selected processor does not support `strexb
> > r3,r2,[r1]' in ARM mode
>
> I think the answer might be to switch to the fallback atomics
> implementation on armel. I'm testing a patch on amdahl, but it's going
> to take a while to get a result.
I tried the attached patch and the build gets a lot further, but then
the final link fails for the same reason that I described in #1017979
(which is not a regression in mozjs102, mozjs91 has the same failure).
As a result of the final link failing, I don't know whether tests will
pass with this patch.
The next thing I'm going to try is using gcc 11 on armel as a workaround
for #1017979.
smcv
Re: Bug#1017961: mozjs102: Fails to build on armel
On Mon, 22 Aug 2022 at 20:25:17 -0400, Jeremy Bicha wrote:
> I did notice this repeatedly in the build log:
>
> {standard input}: Assembler messages:
> {standard input}: Error: selected processor does not support `dmb sy'
> in ARM mode
> {standard input}: Error: selected processor does not support `ldrexb
> r0,[r1]' in ARM mode
> {standard input}: Error: selected processor does not support `strexb
> r3,r2,[r1]' in ARM mode
I think the answer might be to switch to the fallback atomics
implementation on armel. I'm testing a patch on amdahl, but it's going
to take a while to get a result.
smcv
