WebKitGTK JIT crashes on aarch64 hardware with new ARMv8.5 BTI
extension, most commonly seen on M2 Macs running Fedora Asahi. This
breaks large parts of GNOME using WebKitGTK, notably GNOME Online
Accounts; GNOME Help; and other similar things.
This removes Asahi specific changes as this could occur on any aarch64
hardware with this feature and makes WebKitGTK pretty much unuseable
without this change.
We also reduced generated debuginfo for aarch64 here as the memory
requirements are pretty huge for -g, making aarch64 rpms unbuildable in
copr without this change.
Reference: https://bugs.webkit.org/show_bug.cgi?id=245697
Related: rhbz#213000
On ppc64le the dwz process gets killed, and on s390x the builders lock
up when running dwz. Disable the dwz optimizations on these arches
until we can get a patch into /usr/bin/find-debuginfo to control dwz
parallelism.
https://sourceware.org/pipermail/debugedit/2023-January/000173.html
webkitgtk builds in koji are now done on 'heavybuilder' aarch64
builders, which have enough RAM to do dwz optimization. Increase the
aarch64 limit to be the same as on x86_64.
This reverts commit cc3da95bc5.
Why? Because this won't build successfully, because I didn't test it
locally since there were only a couple days since .4, but there's a
soname bump because we removed some APIs.
And we're doing a mass rebuild right now, and it's not ideal for that to
pick up a known-bad commit.
This reverts commit ca90fef86e.
It seems %limit_build doesn't work as we'd like it to for debuginfo. The
new more powerful s390x VMs are still being overwhelmed.
JavaScriptCore's JIT crashes on Apple Silicon Macs running Linux such
that the kernel has BTI enabled. This breaks large parts of GNOME using
WebKitGTK, notably GNOME Online Accounts; GNOME Help; and other similar
things.
For the time being, we'll disable JSC JIT when the Asahi SIG builds
WebKitGTK. This makes us take a huge performance hit, but slow WebKit
is better than crashing WebKit.
Reference: https://bugs.webkit.org/show_bug.cgi?id=245697
Related: rhbz#2130009
I don't want to see complaints about internal JSC functions changing. We
have to export internal APIs because we install two shared libs and one
depends on non-public symbols from the other.
- Require 8 GB of RAM per vCPU for debuginfo processing
This should reduce the debuginfo processing parallelization enough so
that low memory builders don't OOM during the debuginfo processing.
This reverts commit 0ece072912.
