Firefox 105 on POWER


Firefox 105 is out. No, it's not your imagination: I ended up skipping a couple versions. I wasn't able to build Firefox 103 because gcc 12 in Fedora 36 caused weird build failures until it was finally fixed; separately, building 104 and working more on the POWER9 JavaScript JIT got delayed because I'd finally had it with the performance issues and breakage in GNOME 42 and took a couple weeks renovating Plasma so I could be happy with my desktop environment again. Now I'm on track again with everything hopefully maintainable and my workflows properly restored, and we're back to the grind with both those concerns largely resolved.

Unfortunately, we have a couple new ones. Debug builds broke in Fx103 using our standard .mozconfig when mfbt/lz4/xxhash.h was upgraded, because we compile with -Og and it wants to compile its functions with static __inline__ __attribute__((always_inline, unused)). When gcc builds a deoptimized debugging build and fails to inline those functions, it throws a compilation error, and the build screeches to a halt. (This doesn't affect Fedora's build because they always build at a sufficient optimization level such that these functions do indeed get inlined.) After a little thinking, this is the new debug .mozconfig:

export CC=/usr/bin/gcc
export CXX=/usr/bin/g++

mk_add_options MOZ_MAKE_FLAGS="-j24" # or as you likez
ac_add_options --enable-application=browser
ac_add_options --enable-optimize="-Og -mcpu=power9 -fpermissive -DXXH_NO_INLINE_HINTS=1"
ac_add_options --enable-debug
ac_add_options --enable-linker=bfd
ac_add_options --without-wasm-sandboxed-libraries

export GN=/home/censored/bin/gn # if you haz
This builds, or at least compiles, but fails at linkage because of the second problem. This time, it's libwebrtc ... again. To glue the Google build system onto Mozilla's, there is a fragile and system-dependent permuting-processing step that again has broken and Mozilla would like a definitive fix. Until then, we're high and dry because the request is for the generated build file to be generated correctly rather than just patching the generated build file. That's a much bigger knot to unravel and building the gn tool it depends on used to be incredibly difficult (it's now much easier and I was able to upgrade, but all this has done is show me where the problem is and it's not a straightforward fix). If this is not repaired, then various screen capture components used by libwebrtc are not compiled, and linking will fail. Right now it looks like we're the only platform affected even though aarch64 has been busted by the same underlying issue in the past.

The easy choice, especially if you don't use WebRTC, is just add ac_add_options --disable-webrtc to your .mozconfig. I don't use WebRTC much and I'm pretty lazy so ordinarily I would go this route — except you, gentle reader, expect me to be able to tell you when Firefox compiles are breaking, so that brings us to the second option: Dan Horák's patch. This also works and is the version I'm typing into now. Expect you will have to carry this patch in your local tree for a couple versions until this gets dealt with.

Fortunately, the PGO-LTO patch for Firefox 101 still applies to Fx105, so you can still use that. While the optimized .mozconfig is unchanged, here it is for reference:

export CC=/usr/bin/gcc
export CXX=/usr/bin/g++

mk_add_options MOZ_MAKE_FLAGS="-j24" # or as you likez
ac_add_options --enable-application=browser
ac_add_options --enable-optimize="-O3 -mcpu=power9 -fpermissive"
ac_add_options --enable-release
ac_add_options --enable-linker=bfd
ac_add_options --enable-lto=full
ac_add_options --without-wasm-sandboxed-libraries
ac_add_options MOZ_PGO=1

export GN=/home/censored/bin/gn # if you haz
export RUSTC_OPT_LEVEL=2
I've got one other issue to settle, and then I hope to get back to porting the JavaScript and Wasm JIT to 102ESR. But my real life and my $DAYJOB interfere with my after-hours hacking, so contributors still solicited so our work can benefit the OpenPOWER community. When it's one person working on it, things are slower.

Comments

  1. Firefox has some kind of fat architectural flaw when it comes to menu handling. The highlighting of the current item in the main menu is delayed by about 1 sec, it's like going back in time 30 years to i386 and Windows 3.0. My system is a Talos II with one Power 9 18 cores and a Radeon Pro WX7100 video card, Fedora 36 with Gnome.

    ReplyDelete
    Replies
    1. I'm wondering if you're just hitting GNOME performance problems. For F36 I still had to redo libgraphene with SIMD (not sure why this isn't sticking with Fedora's build arch) and GNOME 42 has this annoying periodic stutter every few seconds or so. That's why I eventually junked it and went entirely to KDE Plasma, and pretty much none of that happens anymore.

      Delete
    2. to really get the benefit of fixed graphene, you also need to rebuild all dependents of it (which includes mutter) because a fair amount of the graphene SIMD stuff is actually inline functions in the headers (so rebuilding only graphene itself will get you only a small portion of the fix)

      Delete
    3. The menu in the Gnome applications works flawlessly, Java applications also work properly. Such NetBeans 15 compared to Firefox is a rocket, nothing stutters.

      Delete
    4. | think the menu became slow with a specific FF release (I am not using GNOME, but XFCE instead) ...

      Delete
  2. fyi, i fixed the remaining leftover issue when building firefox/ppc64le with clang (you know, the one with the bookmarks system error)

    it turned out to be sqlite's code being crap as usual (at first i did not realize that firefox was always using bundled sqlite now, so it did not occur to me to look there): https://github.com/chimera-linux/cports/commit/20c3d9509b49e26ff8fb37d6192fdacc1625d083

    before: https://i.imgur.com/8stSLWC.png
    after: https://i.imgur.com/aVIjWMG.png

    ReplyDelete
    Replies
    1. This looks nearly the same underlying issue as that NSS patch we talked about awhile ago? I've just been slack on upstreaming that.

      Delete
    2. it's a different bug but with nearly the same cause (in nss it was __ppc64__ enabling code that should not be, here it's __ppc__ making sqlite using the wrong endianness)

      the two patches => firefox fully works

      Delete

Post a Comment

Comments are subject to moderation. Be nice.