Add PPC64 JIT support for latest upstream codes

[runlevel5]

PPC64 JIT support for Firefox 154+

Brings JIT compilation to PPC64 — both little-endian (ppc64le) and big-endian (ppc64/ppc64be, ELFv1 and ELFv2) — targeting POWER8+ (ISA v2.07+) with POWER9 (ISA v3.0) / POWER10 (ISA 3.1) optimizations. Enables SpiderMonkey's Baseline interpreter, Baseline and Ion JIT compilers, the native regexp JIT, plus full WebAssembly support — tiering, SIMD, huge memory, JSPI, tail calls, and atomics.

This PR revives the JIT port https://github.com/chmeeedalf/gecko-dev by Cameron Kaiser (@classilla) and Justin Hibbits (@chmeeedalf).

This PR would always track against the latest upstream. If you are a packager, please find downstream patches in Releases, if the version you are after are not there, please simply leave a comment in this PR and I will prepare the patches for you.

If you are after the ESR 153 support, please check out #2

Test results

In tests, we trust!

Real little-endian POWER8 hardware (SpiderMonkey with debug, GCC 14, sponsored by Oregon State University):

Suite	POWER8 default
Full jit-tests (--jitflags=all)	13,715 / 0
Full jstests (JSPI on)	PASSED ALL

Real little-endian POWER9 hardware (SpiderMonkey with debug, GCC 16, sponsored by Raptor Computing System):

Suite	POWER9 default	MOZ_PPC64_FORCE_POWER8=1
Full jit-tests (--jitflags=all)	13,715 / 0	13,715 / 0
Full jstests (JSPI on)	PASSED ALL	PASSED ALL

Real little-endian POWER10 hardware (SpiderMonkey with debug, GCC 14, sponsored by Oregon State University):

Suite	POWER10 default	MOZ_PPC64_FORCE_POWER9=1	MOZ_PPC64_FORCE_POWER8=1
Full jit-tests (--jitflags=all)	13,715 / 0	13,715 / 0	13,715 / 0
Full jstests (JSPI on)	PASSED ALL	PASSED ALL	PASSED ALL

ARM64-host simulator for ppc64le:

Suite	FORCE_POWER8=1	FORCE_POWER9=1	FORCE_POWER10=1
Full jit-tests	13,715 / 0	13,715 / 0	13,715 / 0
Full jstests (JSPI on)	PASSED ALL †	PASSED ALL †	PASSED ALL †

† shell/os.js ("killed process should not have exitStatus") was a parallel-load flake on slower hosts — the test sent SIGINT to a sleep 60 child and could lose the signal-delivery race under heavy concurrent jstests load, then waitpid blocked until the child exited normally and the assertion failed. Fixed 2026-05-08 by switching to SIGKILL (which is uncatchable, atomic, and works under any load). Patch in this PR.

FORCE_POWER10=1 implies FORCE_POWER9=1 (matches what real-P10 silicon advertises in hwcap2 — both ARCH_3_00 and ARCH_3_1). Six clean sweeps total — zero hard FAIL, zero TIMEOUT.

Real big-endian POWER9 hardware — ELFv1 (Debian ppc64) and ELFv2 (Arch POWER ppc64), SpiderMonkey debug shell:

Host	Tier	Full jit-tests (--jitflags=all)	Full jstests
ELFv1	default (P9)	0 correctness failures (47 timeouts ‡)	0 unexpected / ~53,940 pass
ELFv1	MOZ_PPC64_FORCE_POWER8=1	0 correctness failures (46 timeouts ‡)	0 unexpected / ~53,940 pass
ELFv2	default (P9)	0 correctness failures (5 timeouts ‡)	0 unexpected / ~53,940 pass
ELFv2	MOZ_PPC64_FORCE_POWER8=1	0 correctness failures (7 timeouts ‡)	0 unexpected / ~53,940 pass

‡ Same small set of legitimately slow tests under --jitflags=all's heaviest combinations (e.g. --no-blinterp --no-baseline --no-ion --more-compartments, gc/bug-2049401.js) exceeding the harness's default timeout under shared-host CPU contention — both boxes are VMs sharing hardware with other work. The identical test/flag combination also times out on real little-endian POWER10, confirming host-load noise rather than an endianness or correctness issue; every affected test passes cleanly when re-run in isolation.

Big-endian (ppc64be) support

The same backend runs big-endian, on both the ELFv1 and ELFv2 ABIs, across POWER8/9/10:

• All execution tiers — Baseline interpreter, Baseline JIT, Ion, and the native regexp JIT.
• Full WebAssembly, including SIMD and atomics. v128 values follow a canonical little-endian register convention; linear memory, globals, atomics, and the JS↔wasm boundary byte-reverse only where the spec observes byte order.
• ABI handling gated on _CALL_ELF, not byte order — big-endian ELFv2 shares the little-endian call paths (no function descriptors), while ELFv1 uses {entry, TOC, env} descriptors for the JIT / regexp / wasm entry trampolines and symbolic-address calls.
• Byte-order fixes for JIT entry stubs, bailout stack slots, wasm stack arguments/results, and mozilla::Result narrow storage. jit-test and wasm spec-harness cases that hard-coded little-endian byte order are made endian-neutral.

Big-endian rendering (full browser)

Firefox on big-endian renders correctly — confirmed on real X11, pixel-verified (correct chrome, page background, link colors, text, and DevTools UI) — via a fourth layer of endian work beyond the JIT itself:

• NSS GHASH hardware acceleration — the vendored PPC64 vpmsumd-based GHASH (AES-GCM) is made endian-correct rather than stubbed out on big-endian, plus a companion fix for a real (both-endian, not just BE) gcm.c/ghash-ppc.c struct-layout mismatch that corrupted the hardware GHASH dispatch and crashed on the first real TLS 1.3 handshake.
• libwebp VSX decode kernels — the WMERGEH/WMERGEL widening-merge fix, same underlying issue class as the GHASH fix: GNU C vector element indexing is memory-order, so a widening merge lands in the opposite half on big-endian.
• Skia + software WebRender — big-endian used to flip Gecko's OS_RGBA surface-format synonym to a memory layout (A8R8G8B8) that Skia has no color type for, hitting MOZ_DIAGNOSTIC_CRASH("A8R8G8B8 unsupported by Skia") on the first paint. Fixed by keeping the whole pixel pipeline on one layout (Skia's little-endian value convention) and converting only at the two real boundaries: Skia's scalar blitters (fills, AA text, LCD subpixel text, glyph masks — via a BE_CONVERT macro, no-op on little-endian) and the software-WebRender→X11 handoff (dirty-region swizzle in RenderCompositorSWGL).
• Known remaining gap: SkRasterPipeline's load/store stages (used for gradients and image sampling through Skia) are unchanged and still assume little-endian — content exercising that path may still show incorrect colors on big-endian. Not yet hit by the JS/DOM-heavy jit-test and jstests suites above, which is why it wasn't caught by that matrix; flagging here rather than leaving it silently uncovered.

Scope

• 19 new files in js/src/jit/ppc64/ — ~17,500 lines.
• Modifications to ~60 shared files (dispatch headers, build system, wasm, CacheIR, MacroAssembler, WasmStacks).
• Full Firefox browser builds successfully (GCC + lld).

What's new vs the old chmeeedalf/gecko-dev Firefox-86 port

Inherited: Architecture-ppc64.h register/ABI constants, the Assembler-ppc64.h/cpp instruction-encoding skeleton, some basic MacroAssembler patterns.

New in this port:

• Build system integration (js/moz.configure, dispatch headers, js/src/jit/moz.build).
• Full WebAssembly — baseline + Ion, tiering, signal handlers, builtins, tail calls, atomics, huge memory, SIMD, JSPI. The old fork had zero Wasm.
• Wasm SIMD — complete VMX/VSX (~280 methods), all 10 tiers, full spec tests, both P8 and P9.
• Warp/Ion backend — complete CodeGenerator, Lowering visitors, LIR-ppc64 (old fork predated Warp).
• Atomic operations — ~980 lines of CompareExchange / AtomicExchange / AtomicFetchOp.
• POWER8/9/10 runtime detection via getauxval(AT_HWCAP2), with fallback sequences for every POWER9-only instruction and POWER10 fast paths gated on HasPOWER10().
• Code-size optimizations — inline constant pool for SIMD + FP constants, POWER9 addpcis FP-constant path, POWER10 prefix-instruction fast paths (see below), GCC-style lis+ori+rldimi 64-bit load (~37 % smaller than a bcl-based stanza).
• Long-branch relocation, OSI epilogue padding, QEMU-style FlushICache.

Key architecture-specific features

Runtime POWER8/POWER9/POWER10 selection

Detection via getauxval(AT_HWCAP2) — PPC_FEATURE2_ARCH_3_00 for POWER9, PPC_FEATURE2_ARCH_3_1 for POWER10.

• POWER9 native paths (with P8 fallbacks): cnttzd/w, xxbrd, mtvsrws, mcrxrx, addpcis, modsw/u/d/du, vinsert{b,h} (lane insert from VR + immediate byte position), xxinsertw, mfvsrld, mtvsrdd, xs{min,max}jdp, xxspltib, vcmpne{b,h,w}, vneg{w,d}, isel, xscvdphp/xscvhpdp (FP16 scalar conversion), xsxexpdp (P9 exponent extract for nearbyIntDouble). replaceLaneInt{8x16,16x8} on POWER9 emits the 2-insn mtvsrd + vinsert{b,h} sequence (down from 5 insns). clampDoubleToUint8 is fully branchless on P9 via xsmaxjdp + isel — the canonical JS clamp shape collapses to a 4-insn straight-line sequence.
• POWER10 fast paths (gated on HasPOWER10()):
  • Prefix-instruction memory traffic — generic, not constants-only.
    • Loads (Address operands when displacement exceeds 16 bits): loadPtr → pld, loadDouble → plfd, loadFloat32 → plfs, loadUnalignedSimd128 → plxv. Replaces the prior addis + ori + ldx-style two-insn stanzas with one prefixed insn.
    • Stores (same shape): storePtr → pstd, storeDouble → pstfd, storeFloat32 → pstfs, storeUnalignedSimd128 → pstxv.
    • Constant materialisation: loadConstantSimd128 3 + xxpermdi → 1 plxv; loadConstantDouble/Float32 2 → 1 plfd/plfs; movePtr(ImmWord) 33–34-bit signed 5 → 1 paddi.
  • Single-instruction lane / byte-reverse / lane-insert collapses: brd collapses byteSwap64 3 → 1 + drops the GPR↔FPR round-trip; brh/brw collapse byteSwap16{Sign,Zero}Extend/byteSwap32 from 3-4 → 2; vinsw/vinsd collapse replaceLaneInt{32x4,64x2} from 2 → 1 (no scratch VSR); vinsbrx/vinshrx cover the same byte/halfword replaceLane on POWER10; vextract{b,h,w,d}m collapses bitmask to 1 insn; vmulld collapses mulInt64x2 from 9-11 insns to 1.
  • CR-bit-to-GPR collapses via setbc/setbcr: 1-insn ma_cmp_set, 1-insn allTrueInt* CR6.EQ extract, and 5 → 3 insn anyTrueSimd128. Replaces the older mfocrf + rlwinm + andi. extraction pattern across the boolean-reduction family.

Test with MOZ_PPC64_FORCE_POWER8=1 (downgrade), MOZ_PPC64_FORCE_POWER9=1 (force P9 on, useful under sim), or MOZ_PPC64_FORCE_POWER10=1 (which implies FORCE_POWER9=1 — matches real-P10 silicon detection). All three configurations PASS the full jit-test + jstests sweeps end-to-end on the simulator.

POWER10 prefix-instruction support

Power ISA v3.1 prefixed instructions are 8 bytes (4-byte prefix word with primary opcode 1 + 4-byte suffix word) and must not straddle a 64-byte aligned block at runtime. The assembler emits them via as_paddi / as_pld / as_plxv / as_plfd / as_plfs, with an automatic leading-nop guard when the prefix would otherwise cross the boundary.

The original guard checked (currentOffset() & 63) == 60 — a buffer-relative test that's only correct when the JitCode allocator base is 64-byte aligned. The allocator only guarantees 16-byte alignment, so across the four base-mod-64 classes {0, 16, 32, 48} the unsafe straddle is exactly (currentOffset() & 15) == 12. The same fix shape applies to the inline-emit path (ensurePrefixedAlignment, commit 8ae818d0fcab) and the constant-pool patcher (PatchConstantPoolLoad, commit aea233e21209). The simulator's POWER10 model doesn't trap misaligned prefixes, which is why these only surfaced when real-P10 silicon came online.

The simulator decodes prefixed instructions, validated against as -mpower10 + objdump on Fedora 44 / binutils 2.46. Encoding details (MLS Type=2 vs 8LS Type=0 vs 8RR Type=1, R-bit at LE position 20, plxv 5-bit suffix opcode + TX bit at suffix bit 26) live in Simulator-ppc64.cpp source comments and PLAN.md's engineering-lessons section.

WASM SIMD

Full VMX/VSX implementation using PPC64 AltiVec. All 10 tiers — load/store/splat/lane, bitwise, arithmetic, cmp/shift, float, conversions, shuffle/swizzle, extmul/pairwise/dot, relaxed SIMD (FMA/FNMA). NaN semantics correct (min/max propagation, truncSat NaN→zero, promote NaN-quieting). P8 uses lxvd2x/stxvd2x with byte-swap; P9 uses native lxvx/stxvx; P10 collapses the constant-pool variant to a single plxv.

WASM JSPI

WebAssembly.Suspending / WebAssembly.promising via javascript.options.wasm_js_promise_integration. Add ppc64 to the JSPI whitelists in js/moz.configure (both the default_wasm_jspi simulator allowlist and the wasm_jspi simulator-guard die-list — extending the original target.cpu enable to cover sim builds too), and round ContRedZoneSize up to a page-size multiple so the bottom guard page lands on a page boundary under PPC64LE's 64 KiB pages. No arch-specific stack-switch code required.

WASM huge memory

4 GB + 32 MB virtual reservation per wasm memory, bounds-check elimination via SIGSEGV → wasm trap. Signal-handler context indices: gp_regs[32]=NIA, gp_regs[1]=SP, gp_regs[31]=FP, gp_regs[36]=LR.

Simulator (ARM64-host)

A full PPC64 simulator is included so CI can run the JIT on non-PPC64 hosts. Both jit-test and jstests sweeps pass under FORCE_POWER8=1, FORCE_POWER9=1, and FORCE_POWER10=1 configurations (zero hard FAIL, zero TIMEOUT). The sim received many ISA-correctness fixes during development (VMX/VSX decoding, LE lane ordering, FP NaN-payload preservation across f32↔f64, ELFv1 FP-arg shadow slots, single-step profiling for tail calls and non-leaf epilogues), and now decodes:

• Power ISA v3.0 (POWER9): addpcis, mods*/modu*, mtvsrws, xxspltib, xxinsertw, xscvdpsp(n) HW-conformance fix, xs{max,min}jdp, xscvdphp/xscvhpdp (FP16), xsxexpdp. Closes the historical "~40 wasm/simd tests fail under FORCE_POWER9 on the sim" coverage gap.
• Power ISA v3.1 (POWER10): prefixed instructions (paddi/pld/plxv/plfd/plfs), plus the new instruction-count-reduction ops (brd, brh, brw, vinsw, vinsd, vinsbrx, vinshrx, vextract*m, setbc/setbcr, vmulld).
• A simulator-side setXEROV() fix that mirrors OV→OV32 — the JIT's branchMulPtr Overflow path uses POWER9's mcrxrx+bc which reads OV32, and the original sim only set OV. Surfaced as silent BigInt fast-path-mul wrap-around in wasm/regress/bug1836708.js.

Build

Complete from-scratch walkthrough — little-endian (Debian / Ubuntu / Fedora, ppc64le)

Mozilla's ./mach bootstrap cannot download prebuilt toolchains for ppc64, so
everything comes from your distro plus rustup. These steps take a fresh
ppc64le machine to a running browser. Big-endian Debian has its own section
right after this one.

Verified end-to-end on a clean Debian 13 (trixie) ppc64le container on real
POWER9 hardware: these exact commands produce a working firefox binary.

1. Install build dependencies.

Debian / Ubuntu — let apt resolve the whole Firefox dependency tree, then add
the handful of pieces it misses:

# Enable source repositories first:
#   Debian 12+: add "deb-src" lines matching your "deb" lines in
#   /etc/apt/sources.list, or Types: deb deb-src in /etc/apt/sources.list.d/debian.sources
sudo apt update
sudo apt build-dep firefox-esr        # bulk of the dependencies
sudo apt install git curl ccache python3-venv python3-pip \
                 pkg-config nasm nodejs npm libclang-dev clang lld

Fedora:

sudo dnf builddep firefox
sudo dnf install git curl ccache nasm nodejs clang clang-devel lld

2. Install Rust and cbindgen via rustup. Distro packages are almost
always too old — this tree requires Rust >= 1.90 and cbindgen >= 0.29.4
(node only needs >= 12, any current distro package is fine):

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
source ~/.cargo/env
rustup default stable
cargo install cbindgen

Make sure ~/.cargo/bin stays on PATH for every build shell.

3. Clone this repository and branch.

git clone --branch ppc64 https://github.com/runlevel5/firefox-ppc64.git
cd firefox-ppc64

(For ESR 153 use --branch esr153-ppc64, see PR #2. Packagers who prefer
patch files over a git checkout: apply the numbered patches from
Releases on top of the
matching Mozilla release tarball instead.)

4. Write a mozconfig. Create a file named mozconfig in the tree root
with one of the configurations below (JS shell, full Firefox GCC, or full
Firefox Clang+LTO). Two lines matter on ppc64 no matter which you pick:

ac_add_options --disable-bootstrap                  # never try to fetch Mozilla toolchains
ac_add_options --without-wasm-sandboxed-libraries   # no wasi sysroot for ppc64

5. Build and run.

./mach build
./mach run          # run from the object directory
./mach package      # or produce a distributable tarball in <objdir>/dist/

Hardware/RAM notes: linking libxul.so with lld peaks around 8 GB;
16 GB RAM is a comfortable minimum for the full browser (the JS shell builds
on much less). On bigger machines cap parallelism (mk_add_options MOZ_PARALLEL_BUILD=20) rather than letting mach use every core — wide lld
links can OOM the box.

Troubleshooting:

• mach fails creating its virtualenv → sudo apt install python3-venv.
• configure errors about Rust or cbindgen versions → check rustc --version
  (>= 1.90) and cbindgen --version (>= 0.29.4); the rustup/cargo copies in
  ~/.cargo/bin must precede any distro copies on PATH.
• configure cannot find libclang → install libclang-dev (Debian) /
  clang-devel (Fedora) and point --with-libclang-path at the directory
  containing libclang.so (llvm-config --libdir).
• OOM during the final link → lower MOZ_PARALLEL_BUILD, ensure the linker
  is lld (--enable-linker=lld), add swap/zram.
• Big-endian: see the next section.

Complete walkthrough — big-endian Debian (ppc64, ELFv1)

Big-endian Debian is an unofficial port living in debian-ports (sid only),
and the ELFv1 ABI changes the toolchain rules: lld cannot link ELFv1 at
all, and Debian's clang forces lld — so the build must use GCC with GNU
ld (bfd) for both target and host. Steps 2, 3 and 5 from the
little-endian walkthrough apply unchanged (rustup supports big-endian
powerpc64-unknown-linux-gnu); the differences:

1. Dependencies. On a debian-ports sid system:

sudo apt update
sudo apt build-dep firefox-esr   # if firefox-esr is unavailable in ports, use:
sudo apt install build-essential git curl ccache python3-venv python3-pip \
                 pkg-config nasm m4 unzip zip \
                 libgtk-3-dev libdbus-glib-1-dev libpulse-dev libasound2-dev \
                 libxt-dev libx11-xcb-dev libpixman-1-dev \
                 nodejs npm libclang-dev

4. mozconfig for big-endian ELFv1:

export CC=gcc
export CXX=g++
ac_add_options --enable-application=browser
ac_add_options --enable-optimize
ac_add_options --disable-debug
ac_add_options --enable-release
ac_add_options --disable-tests
ac_add_options --enable-jit
ac_add_options --disable-bootstrap
ac_add_options --with-libclang-path=`llvm-config --libdir`
ac_add_options --without-wasm-sandboxed-libraries
ac_add_options --enable-linker=bfd
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff-ppc64be

Big-endian caveats:

• bfd needs substantially more RAM than lld to link libxul.so
  (community reports ~20 GB resident); on smaller machines build the JS shell
  (--enable-application=js), which links fine everywhere.
• The DevTools build step needs a working Node.js, and Debian's big-endian
  nodejs currently segfaults on it — see the dedicated Node.js
  bootstrap section below for the two workarounds (DevTools-server-only
  build, or forwarding node to a little-endian helper host).
• cbindgen must still come from cargo install cbindgen — the ports archive
  version is too old.
• Big-endian ELFv2 distros (e.g. Arch POWER) use the same recipe minus the
  ELFv1 constraint origin — but clang's forced lld still applies on Debian
  derivatives, so GCC + bfd remains the safe choice on any big-endian
  system.

mozconfig reference

SpiderMonkey (standalone JS shell):

ac_add_options --enable-application=js
ac_add_options --enable-optimize
ac_add_options --disable-debug
ac_add_options --disable-tests
ac_add_options --enable-jit
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-sm-release

./mach build -j20

(On the PPC64 box, cap parallelism at -j20; the auto-detected -j32 saturates the box during lld linking.)

Full Firefox:

export CC=gcc
export CXX=g++
ac_add_options --enable-application=browser
ac_add_options --enable-optimize
ac_add_options --disable-debug
ac_add_options --enable-release
ac_add_options --disable-tests
ac_add_options --enable-jit
ac_add_options --disable-bootstrap
ac_add_options --with-ccache
ac_add_options --with-libclang-path=/usr/lib64
ac_add_options --without-wasm-sandboxed-libraries
ac_add_options --enable-linker=lld
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff-ppc64

./mach build -j20

Full Firefox with Clang + LTO (ppc64le):

A Clang + ThinLTO build works on ppc64le and is measurably faster on
DOM/layout-heavy workloads than the plain GCC -O2 build. Two things make it
work: Clang with the LLVM linker (lld), and system NSS — the bundled
NSS ppc-gcm.s uses GAS-style semicolon statement separators that Clang's
integrated assembler rejects, so building against the distro's NSS
(--with-system-nss) sidesteps that entirely. This is exactly what the Fedora
package build does.

export CC=clang
export CXX=clang++
ac_add_options --enable-application=browser
ac_add_options --enable-optimize
ac_add_options --disable-debug
ac_add_options --enable-release
ac_add_options --disable-tests
ac_add_options --enable-jit
ac_add_options --disable-bootstrap
ac_add_options --enable-linker=lld
ac_add_options --enable-lto              # ThinLTO
ac_add_options --with-system-nss         # avoids Clang IAS choking on NSS ppc-gcm.s
ac_add_options --with-system-nspr
ac_add_options --with-libclang-path=`llvm-config --libdir`
ac_add_options --without-wasm-sandboxed-libraries
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff-clang

./mach build -j20

Do not add PGO on ppc64le. Profile-guided optimization is currently
broken on this target — GCC ICEs during the instrumented build and Clang's
instrumented build crashes at runtime (see
DKnoto/Firefox-Benchmarks).
LTO alone is the supported configuration.

--with-libclang-path must point at the directory that actually holds
libclang.so. On distros that version the LLVM tree (e.g. Fedora's
/usr/lib64/llvm22/lib64) let llvm-config --libdir resolve it rather than
hard-coding /usr/lib64.

For RPM packagers: the Fedora spec builds this with
rpmbuild --with build_with_clang --with build_with_lto.

Big-endian (ppc64be): Node.js bootstrap

The full browser build runs Node.js at build time to transform the DevTools
debugger modules (devtools/client/* via mozbuild/action/node.py). Nothing
Node produces ships in the binary — it is a build-time tool only — but the
build cannot finish without it, and Node on big-endian ppc64 is currently a
problem:

• Mozilla ships no prebuilt Node toolchain for ppc64, so the build needs a
  system Node.
• Debian's ppc64 (BE) nodejs is an unofficial port frozen at 20.19.5 and
  its libnode segfaults during a V8 conservative-stack-scan GC
  (heap::base::Stack::IteratePointersImpl) when running the DevTools
  transform — an endianness-specific V8/Node bug, unrelated to this port.

Two ways to get past it:

1. Skip the DevTools client (simplest). Set the DevTools build to
server instead of all. This drops the browser-side debugger UI but keeps
the DevTools server (remote debugging still works) and needs no Node:

export MOZ_DEVTOOLS=server   # requires a one-line source edit; see note below

MOZ_DEVTOOLS cannot be set from mozconfig (it is an imply_option), so
change imply_option("MOZ_DEVTOOLS", "all") to "server" in
browser/moz.configure, or wait for a proper --disable-devtools-style knob.

2. Offload Node to a working host (full DevTools). If you have a
little-endian ppc64le box (or any box with a working Node), run only the Node
steps there while the compile stays on the BE machine. Node just reads/writes
files in the source and object trees, so share the tree and forward node:

• On the LE helper, mount the BE build tree (e.g. via sshfs) and confirm its
  Node runs devtools/client/shared/build/build.js without crashing.
• On the BE box, put a node wrapper first on PATH that sshes the command
  to the helper, rewriting the tree-path prefix (BE mountpoint ↔ helper
  mountpoint) in both the arguments and in the dep: lines Node prints back
  (the build system consumes those for incremental rebuilds):

#!/bin/bash
# ~/nodewrap/node  — forward Node to an LE helper that shares this tree.
LOCAL=/path/to/be/firefox          # tree path on the BE box
REMOTE=/path/to/helper/mount       # same tree, as seen on the helper
args=(); for a in "$@"; do args+=("${a//$LOCAL/$REMOTE}"); done
out=$(ssh helper "cd $(printf %q "${PWD//$LOCAL/$REMOTE}") && \
      node $(printf '%q ' "${args[@]}")"); rc=$?
printf '%s\n' "${out//$REMOTE/$LOCAL}"; exit $rc

PATH=~/nodewrap:$PATH ./mach build -j20

Longer term the clean fix is a Node that does not crash on ppc64 BE (e.g.
building Node from source — Arch POWER's nodejs-lts-iron recipe builds
20.20.0 for powerpc64 with --with-intl=system-icu).

Known limitations

• Clang full Firefox: works with --with-system-nss + lld (see the Clang + LTO build recipe above). Only the bundled NSS is a problem — its ppc-gcm.s uses GAS-style semicolons that Clang's integrated assembler rejects — so building against the distro NSS avoids it. PGO is still unavailable on ppc64le (GCC ICE / Clang runtime crash); LTO-only.
• ld.bfd: does link libxul.so successfully on ppc64le, but needs substantially more RAM during the link than lld (community reports ~20+ GiB resident, putting it out of reach for hosts with under ~24 GiB total). The P10 box uses BFD as a workaround for an LLD R_PPC64_TOC16_HA bug; lld stays the practical default everywhere else for speed.

TODO

• Wrap up and ask @classilla to review and help with upstreaming: https://bugzilla.mozilla.org/show_bug.cgi?id=1860412
• Upstream SKIA with Google
• Upstream libwebp with Google

[runlevel5]

@classilla @carlosgonz0 @chmeeedalf please feel free to give this PR a try. I have tried to hand test it as much as possible but I am sure I might have missed some edge cases

[runlevel5]

Proposed in https://bugzilla.mozilla.org/show_bug.cgi?id=1954438

[sharkcz]

FWIW it seems ld.bfd can link libxul.so on my Fedora 42 (256 GB system) ...

[runlevel5]

FWIW it seems ld.bfd can link libxul.so on my Fedora 42 (256 GB system) ...

@sharkcz that's ALOT of RAM you have. It's good to know it does work, let me update the notes

[runlevel5]

@sharkcz I believe you have POWER8 hardware, wondering if you could help run full jit-test and jstests for me and let me know the results? Many thanks

[sharkcz]

@sharkcz I believe you have POWER8 hardware, wondering if you could help run full jit-test and jstests for me and let me know the results? Many thanks

yes, I should be able to run the tests on a P8 system. What is the procedure you are using?

[runlevel5]

yes, I should be able to run the tests on a P8 system. What is the procedure you are using?

@sharkcz you need to build the software on your P8 first, check the Build section of the PR description for HOWTO. Then run the tests with ./mach jit-test and ./mach jstests. I've done the test run with POWER8 VM but unsure if it would work the same way with a real non-VM POWER8 (in theory it should be because KVM would translate down to micro-arch of the host right)

[runlevel5]

@sharkcz @kth5 FYI https://github.com/runlevel5/firefox-ppc64/releases/tag/FIREFOX_152_0_5_RELEASE_PPC64 can be cleanly applied with patch. I've converted the binary test WASM file to a WAT format.

[chmeeedalf]

Could someone with better Debian skills than I have build a Debian package, or tell me how to build one? I tried following the Build instructions in the PR description and it threw a very helpful "Error 2" with no visible reason.

[runlevel5]

Could someone with better Debian skills than I have build a Debian package, or tell me how to build one? I tried following the Build instructions in the PR description and it threw a very helpful "Error 2" with no visible reason.

@chmeeedalf FYI I have submitted a patch for Debian downstream package, but that's for Firefox 152. Debian has not yet bumped theirs to 153 or newer.

Could you please let me know which Debian distribution version you are using?

[runlevel5]

@chmeeedalf I've just updated the PR with full instructions for Debian. I got it compile successfully on Debian 13.5

[chmeeedalf]

@runlevel5 great, thanks. I was hoping I could build a .deb package for 14/testing, but probably not going to happen, because the Debian firefox-esr is 140.

[runlevel5]

great, thanks. I was hoping I could build a .deb package for 14/testing, but probably not going to happen, because the Debian firefox-esr is 140.

@chmeeedalf I strongly believe Debian team will soon cut a dedicated git branch for the esr-153. While waiting, nothing stop you from building your own local Debian package. I highly encourage you to chime in https://salsa.debian.org/mozilla-team/firefox/-/merge_requests/17 to bring that work to the attention of the Debian team.

[runlevel5]

@sharkcz is there anything left to do to get the patch officially adopted downstream with Fedora?