Bug#1017961: mozjs102: Fails to build on armel

[Jeremy Bicha]

Source: mozjs102
Version: 102.2.0-1
Severity: important
X-Debbugs-CC: debian-***@lists.debian.org
Tags: ftbfs help

mozjs102 fails to build on armel. This is a problem because it is
blocking us from being able to switch Debian's gjs to use mozjs102
instead of the obsolete mozjs91.

https://buildd.debian.org/status/logs.php?pkg=mozjs102&arch=armel

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

Thank you,
Jeremy Bicha

[Simon McVittie]

Post by Jeremy Bicha
{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

[Simon McVittie]

Post by Simon McVittie

Post by Jeremy Bicha
{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

[Simon McVittie]

Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1786619

Post by Simon McVittie
I tried the attached patch

Sorry, now attached.

Post by Simon McVittie
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

[Simon McVittie]

Post by Simon McVittie
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

[Wookey]

Post by Simon McVittie
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.

Post by Simon McVittie
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

[Jérémy Lal]

Post by Wookey

Post by Simon McVittie
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.

Post by Simon McVittie
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