Hi, This is a follow-up to bug #685150 where dev-lang/spidermonkey:60 was mistakenly keyworded ia64 stable and BR CLOSED as RESOLVED, while it isn't. Please reopen the latter and let's continue the discussion here. In short, =dev-lang/spidermonkey-60.5.2_p0-r2 emerges successfully, even with FEATURES=test enabled (though I don't know if any test-suite is provided in the ebuild) but running js60 from the command-line does absolutely nothing whereas previous js38 was firing up the JS interpreter: js> build() built on Nov 21 2017 at 12:50:26 js> quit() js60 doesn't seem to crash, but I'm unable to rebuild dev-lang/spidermonkey:60 with debugging symbols to double-check with GDB, as =sys-auth/polkit-0.116-r1 installed on my system has a strong dev-lang/spidermonkey:60[-debug] dependency. Diagnosing further, the following conftest.cpp code sample (adapted from =dev-libs/gjs-1.54.3 config scripts) fails with: js::jit::InitProcessExecutableMemory() failed int main () { if (!JS_InitWithFailureDiagnostic()) exit(1); JS_ShutDown(); return 0; } Compiled with: g++ -o conftest -O2 -pipe -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/libffi-3.3_rc0/include -I/usr/include/gobject-introspection-1.0 -pthread -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/uuid -include /usr/include/mozjs-60/js/RequiredDefines.h -I/usr/include/mozjs-60 -I/usr/include/nspr -Wl,-O1 -Wl,--as-needed conftest.cpp -lgirepository-1.0 -lffi -pthread -lgthread-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lmozjs-60
emerge --info output: Portage 2.3.79 (python 3.6.9-final-0, default/linux/ia64/17.0/desktop/gnome, gcc-9.2.0, glibc-2.29-r7, 4.19.86-gentoo ia64) ================================================================= System uname: Linux-4.19.86-gentoo-ia64-Madison-with-gentoo-2.6 KiB Mem: 24982256 total, 16569328 free KiB Swap: 499696 total, 499696 free Timestamp of repository gentoo: Fri, 20 Dec 2019 20:00:01 +0000 Head commit of repository gentoo: fe7cd2cd1ab3fef99e8d61e938a150c6b6193a79 sh bash 4.4_p23-r1 ld GNU ld (Gentoo 2.32 p2) 2.32.0 app-shells/bash: 4.4_p23-r1::gentoo dev-lang/perl: 5.30.1::gentoo dev-lang/python: 2.7.17::gentoo, 3.6.9::gentoo dev-util/cmake: 3.14.6::gentoo sys-apps/baselayout: 2.6-r1::gentoo sys-apps/openrc: 0.41.2::gentoo sys-apps/sandbox: 2.13::gentoo sys-devel/autoconf: 2.13-r1::gentoo, 2.69-r4::gentoo sys-devel/automake: 1.16.1-r1::gentoo sys-devel/binutils: 2.32-r1::gentoo sys-devel/gcc: 9.2.0-r2::gentoo sys-devel/gcc-config: 2.1::gentoo sys-devel/libtool: 2.4.6-r3::gentoo sys-devel/make: 4.2.1-r4::gentoo sys-kernel/linux-headers: 4.19::gentoo (virtual/os-headers) sys-libs/glibc: 2.29-r7::gentoo Repositories: gentoo location: /var/db/repos/gentoo sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 sync-rsync-verify-metamanifest: yes sync-rsync-verify-jobs: 1 sync-rsync-extra-opts: sync-rsync-verify-max-age: 24 localrepo location: /var/db/repos/localrepo masters: gentoo ACCEPT_KEYWORDS="ia64" ACCEPT_LICENSE="@FREE" CBUILD="ia64-unknown-linux-gnu" CFLAGS="-O2 -pipe" CHOST="ia64-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/var/cache/distfiles" ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="ftp://ftp.free.fr/mirrors/ftp.gentoo.org/" LANG="fr_FR.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="fr" MAKEOPTS="-j3" PKGDIR="/var/cache/binpkgs" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="X a52 aac acl acpi alsa berkdb branding bzip2 cairo cdda cdr cli colord crypt cups cxx dbus dri dts dvdr eds elogind encode evo exif fam flac fortran gdbm gif gnome gnome-keyring gnome-online-accounts gpm gstreamer gtk ia64 iconv icu introspection ipv6 jpeg lcms ldap libnotify libsecret libtirpc mad mng mp3 mp4 mpeg nautilus ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio readline sdl spell split-usr ssl startup-notification svg tcpd tiff tracker truetype udev udisks unicode upower usb vorbis wayland wxwidgets x264 xattr xcb xml xv xvid zlib" ADA_TARGET="gnat_2018" ALSA_CARDS="fm801" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput" KERNEL="linux" L10N="fr" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" NETBEANS_MODULES="apisupport cnd groovy gsf harness ide identity j2ee java mobility nb php profiler soa visualweb webcommon websvccommon xml" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" RUBY_TARGETS="ruby24" USERLAND="GNU" VIDEO_CARDS="fbdev radeon r300" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 601860 [details] build.log It fails to run randomly for me: ia64 (CHROOT) ~ $ js60;echo $? 1 ia64 (CHROOT) ~ $ js60;echo $? 1 ia64 (CHROOT) ~ $ js60;echo $? 1 ia64 (CHROOT) ~ $ js60;echo $? 1 ia64 (CHROOT) ~ $ js60;echo $? js> I'm also unable to compile it with USE=debug
(In reply to Agostino Sarubbo from comment #2) > Created attachment 601860 [details] > build.log > > It fails to run randomly for me: > > ia64 (CHROOT) ~ $ js60;echo $? > 1 > ia64 (CHROOT) ~ $ js60;echo $? > 1 > ia64 (CHROOT) ~ $ js60;echo $? > 1 > ia64 (CHROOT) ~ $ js60;echo $? > 1 > ia64 (CHROOT) ~ $ js60;echo $? > js> > > > I'm also unable to compile it with USE=debug I second that: it indeed fails randomly. But it more often fails than it succeeds.
There we go: SpiderMonkey is broken on ia64 since release 45.8.0. I ran a git bisect on upstream esr45 branch (applying above Gentoo's patches for correctly determining libc.so.1 as C library and providing JIT atomics on ia64) and was able to identify the culprit: 52419a78cd379b7b253d405c2ec65421210f10cb is the first bad commit commit 52419a78cd379b7b253d405c2ec65421210f10cb Author: Jan de Mooij <jdemooij@mozilla.com> Date: Sat Feb 4 11:03:58 2017 +0100 Bug 1334933 - Allocate executable pages from a pre-reserved range. r=luke, a=gchang * * * Bug 1334933 - Randomize mmap address for executable code on posix platforms. r=luke * * * Bug 1334933 part 4 - Fix mmap randomization on Linux32 to be within a fixed range to avoid conflicts. r=luke * * * Bug 1337561 - Fix executable page allocator to avoid fragmenting the JIT code space. r=luke js/src/asmjs/AsmJSModule.cpp | 14 +- js/src/gc/GCRuntime.h | 2 +- js/src/irregexp/RegExpEngine.cpp | 3 +- js/src/jit/ExecutableAllocator.cpp | 91 +---- js/src/jit/ExecutableAllocator.h | 55 +-- js/src/jit/ExecutableAllocatorPosix.cpp | 122 ------- js/src/jit/ExecutableAllocatorWin.cpp | 281 --------------- js/src/jit/Lowering.cpp | 4 +- js/src/jit/ProcessExecutableMemory.cpp | 607 ++++++++++++++++++++++++++++++++ js/src/jit/ProcessExecutableMemory.h | 46 +++ js/src/jsgc.cpp | 12 +- js/src/moz.build | 8 +- js/src/shell/js.cpp | 5 - js/src/vm/Initialization.cpp | 6 +- 14 files changed, 689 insertions(+), 567 deletions(-) delete mode 100644 js/src/jit/ExecutableAllocatorPosix.cpp delete mode 100644 js/src/jit/ExecutableAllocatorWin.cpp create mode 100644 js/src/jit/ProcessExecutableMemory.cpp create mode 100644 js/src/jit/ProcessExecutableMemory.h
Looking at commit 52419a78cd379b7b253d405c2ec65421210f10cb in details, it addresses two bugs. Reverting the second one (Bug 1337561 - Fix executable page allocator to avoid fragmenting the JIT code space.) didn't help. I then had a look at the issues addressed in the first bug (Bug 1334933 - Allocate executable pages from a pre-reserved range. and Bug 1334933 - Randomize mmap address for executable code on posix platforms.) where I *think* that it all makes sense. The interesting part lies in the comment of the ComputeRandomAllocationAddress function, most notably: // Return a random, page-aligned address. x64 CPUs have a 48-bit address // space and on some platforms the OS will give us access to 47 bits, so // to be safe we right shift by 18 to leave 46 bits. This immediately rings the alarm bell and reminded me of a very old issue on jemalloc code (https://bugzilla.mozilla.org/show_bug.cgi?id=589735). I suppose that a strategy similar to the then provided patch (https://hg.mozilla.org/integration/mozilla-inbound/rev/9c15d0fb3e25) to get valid memory address locations on ia64 must be integrated in ProcessExecutableMemory.cpp. But here, I don't know where to put the required bits between the ReserveProcessExecutableMemory, {Commit|Decommit}Pages and/or allocate|deallocate functions. @Mozilla team, can you help?
Created attachment 603428 [details, diff] spidermonkey-60.5.2_p0-ia64-jit.patch spidermonkey-60.5.2_p0-ia64-jit.patch to avoid clobbering tag space of virtual address space on ia64.
(In reply to Émeric Maschino from comment #3) > (In reply to Agostino Sarubbo from comment #2) > > Created attachment 601860 [details] > > build.log > > > > It fails to run randomly for me: > > > > ia64 (CHROOT) ~ $ js60;echo $? > > 1 > > ia64 (CHROOT) ~ $ js60;echo $? > > 1 > > ia64 (CHROOT) ~ $ js60;echo $? > > 1 > > ia64 (CHROOT) ~ $ js60;echo $? > > 1 > > ia64 (CHROOT) ~ $ js60;echo $? > > js> > > > > > > I'm also unable to compile it with USE=debug > > I second that: it indeed fails randomly. But it more often fails than it > succeeds. Do you happen to get 75% failure ratio? It looks like we are off-by-2-bits. I wonder if spidermonkey-60.5.2_p0-ia64-jit.patch helps you.
(In reply to Sergei Trofimovich from comment #7) > > Do you happen to get 75% failure ratio? It looks like we are off-by-2-bits. > I wonder if spidermonkey-60.5.2_p0-ia64-jit.patch helps you. No, I rather get 90% failure ratio. Awesome, your patch works like a charm. Many thanks :-) But... well... how did you know that the upper 20 bits (slight typo in your patch: mits -> bits) are reserved for virtual memory type on ia64?
(In reply to Sergei Trofimovich from comment #6) > Created attachment 603428 [details, diff] [details, diff] > spidermonkey-60.5.2_p0-ia64-jit.patch > > spidermonkey-60.5.2_p0-ia64-jit.patch to avoid clobbering tag space of > virtual address space on ia64. Sergei get me a proper git patch with a sign-off and I will be more then happy to commit it to tree.
(In reply to Émeric Maschino from comment #8) > (In reply to Sergei Trofimovich from comment #7) > > > > Do you happen to get 75% failure ratio? It looks like we are off-by-2-bits. > > I wonder if spidermonkey-60.5.2_p0-ia64-jit.patch helps you. > > No, I rather get 90% failure ratio. Oh, then maybe the fix is not quite correct. What page size and page table levels your system has? $ getconf PAGE_SIZE and $ cat /boot/config-`uname -r` | egrep 'CONFIG_IA64_PAGE_SIZE|CONFIG_PGTABLE_LEVELS' should report it. > Awesome, your patch works like a charm. Many thanks :-) > But... well... how > did you know that the upper 20 bits (slight typo in your patch: mits -> > bits) are reserved for virtual memory type on ia64? Virtual memory on 64-bit systems is a hard problem because it's so large. Frequently some bits in virtual addresses are not supported by CPU. For example on AMD64 /proc/cpuinfo's "48 bits virtual" means that your virtual addresses can use only 48 bits. That is visible in things like $ cat /proc/self/maps 5616744b3000-5616744b5000 r--p 00000000 00:12 661194694 /bin/cat 7ffc5f3d5000-7ffc5f3d6000 r-xp 00000000 00:00 0 [vdso] Note how addresses take only 12 digits instead of 16. That is 47 bits (kernel uses negative addresses). On ia64 things are similar but not exactly: 1. ia64 hardware guarantees that usable virtual bits are at least 50 (that is more than on AMD64). 2. upper 3 bits denote a memory region (and that is not a part of implemented virtual bits). Here is the output from 16K page L3 page table ia64 system: $ cat /proc/self/maps 00000000-00004000 r--p 00000000 00:00 0 2000000000050000-200000000005c000 rw-p 00040000 08:03 44952 /lib/ld-2.29.so 60000fffffcd0000-60000fffffcf4000 rw-p 00000000 00:00 0 [stack] a000000000000000-a000000000080000 r-xp 00000000 00:00 0 [vdso] Here 0/2/6/a is a virtual memory region number (numbers 0/1/3/5) and fffffcf4000 is implemented part of virtual memory bits. 4 and above are special regions: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/ia64/include/asm/page.h#n22 Note: (ignoring region) linux uses only 44 non-zero bits of address space. Linux does not implement all the 50+ bits of virtual address. Linux imposes extra restriction on how many bits it can use to resolve virtual address to physical by means of hierarchical page table structure similar to AMD64: On an L3 page table system we have 3 levels of indirection where each table is a table of pointers (and thus depends on page size). For example 16KB pages (14 bits) allow for page tables of 13 bits each (== 16 - 3, as pointers are 8 bytes). Thus maximum virtual address in such a setup is: 11 (L3) - 3 (region) + 11 (L2) + 11 (L1) + 14 (page offset) = 44 bits. For comparison 8K pages would be: 10 (L3) - 3 (region) + 10 (L2) + 10 (L1) + 13 (page offset) = 40 bits. Or 4K would be: 9 (L3) - 3 (region) + 9 (L2) + 9 (L1) + 12 (page offset) = 36 bits. For an L4 page table (for extreve 4K/8K page size) that would be : 4k: 9 (L4) - 3 (region) + 9 (L3) + 9 (L2) + 9 (L1) + 12 (page offset) = 45 bits. 8k: 10 (L4) - 3 (region) + 10 (L3) + 10 (L2) + 10 (L1) + 13 (page offset) = 50 bits. http://www.ia64-linux.org/doc/IA64linuxkernel.PDF has a few nice pics. To conclude: If you have 16K pages 44 bits of virtual space is most you get. Increasing(decreasing) page size twice adds(removes) 4 more bits of extra VA space (16x of space) for L3 schema and 5 more bits for an L4 schema. For worst case 4K for L3 schema we get only 36 bits of address space. (In reply to Jory A. Pratt from comment #9) > (In reply to Sergei Trofimovich from comment #6) > > Created attachment 603428 [details, diff] [details, diff] [details, diff] > > spidermonkey-60.5.2_p0-ia64-jit.patch > > > > spidermonkey-60.5.2_p0-ia64-jit.patch to avoid clobbering tag space of > > virtual address space on ia64. > > Sergei get me a proper git patch with a sign-off and I will be more then > happy to commit it to tree. Will do. Will ponder a bit how to make it dependent on host page size as current hack might not work for systems with a tiny page size.
Created attachment 604118 [details, diff] 0001-ProcessExecutableMemory.cpp-fix-virtual-address-leng.patch 0001-ProcessExecutableMemory.cpp-fix-virtual-address-leng.patch is a variant with dynamic page size detection. Still works on L3/16K system.
(In reply to Sergei Trofimovich from comment #10) > (In reply to Émeric Maschino from comment #8) > > > > No, I rather get 90% failure ratio. > > Oh, then maybe the fix is not quite correct. What page size and page table > levels your system has? > $ getconf PAGE_SIZE > and > $ cat /boot/config-`uname -r` | egrep > 'CONFIG_IA64_PAGE_SIZE|CONFIG_PGTABLE_LEVELS' > should report it. Same configuration than yours: L3 16KB page size. > Virtual memory on 64-bit systems is a hard problem because it's so large. > Frequently some bits in virtual addresses are not supported by CPU. <snip> Thanks for the detailed explanation. I'm not familiar with the /proc/self/maps data, so everything's not clear yet. I need to read again and again to understand how you've computed the final formula, but I get the global idea. > (In reply to Jory A. Pratt from comment #9) > > Will do. Will ponder a bit how to make it dependent on host page size as > current hack might not work for systems with a tiny page size. New patch tested. I can confirm that it still works flawlessly. Thanks, Émeric
(In reply to Jory A. Pratt from comment #9) > (In reply to Sergei Trofimovich from comment #6) > > Created attachment 603428 [details, diff] [details, diff] [details, diff] > > spidermonkey-60.5.2_p0-ia64-jit.patch > > > > spidermonkey-60.5.2_p0-ia64-jit.patch to avoid clobbering tag space of > > virtual address space on ia64. > > Sergei get me a proper git patch with a sign-off and I will be more then > happy to commit it to tree. Any chance to see Sergei's patch (https://bugs.gentoo.org/attachment.cgi?id=604118) commited, please? Thanks, Émeric
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=40244e2b380a51c29d895828c134ca1090810581 commit 40244e2b380a51c29d895828c134ca1090810581 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2020-04-21 11:50:14 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2020-04-21 11:50:14 +0000 dev-lang/spidermonkey: fix virtual address length on ia64 Closes: https://bugs.gentoo.org/703538 Package-Manager: Portage-2.3.99, Repoman-2.3.22 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> ...ey-60.5.2-ia64-fix-virtual-address-length.patch | 59 ++++++++ .../spidermonkey/spidermonkey-60.5.2_p0-r4.ebuild | 155 +++++++++++++++++++++ 2 files changed, 214 insertions(+)
Could you please also give spidermonkey-68.7.0+ a try on ia64?
(In reply to Thomas Deutschmann from comment #15) > Could you please also give spidermonkey-68.7.0+ a try on ia64? Will do. Is Sergei's patch already applied to spidermonkey-68.7.0+?
Created attachment 666236 [details, diff] dev-lang/spidermonkey:68 Add JIT ia64 atomics
Created attachment 666239 [details, diff] dev-lang/spidermonkey:68 JIT Fix virtual address length on ia64
(In reply to Émeric Maschino from comment #16) > (In reply to Thomas Deutschmann from comment #15) > > Could you please also give spidermonkey-68.7.0+ a try on ia64? > > Will do. Is Sergei's patch already applied to spidermonkey-68.7.0+? Sergei's patch isn't applied to dev-lang/spidermonkey:68 :-( Now available in attachment #666239 [details, diff] with attachment #666236 [details, diff] also required to have working dev-lang/spidermonkey:68 on ia64. Émeric
(In reply to Émeric Maschino from comment #19) > > Sergei's patch isn't applied to dev-lang/spidermonkey:68 :-( Now available > in attachment #666239 [details, diff] [details, diff] with attachment #666236 [details, diff] [details, > diff] also required to have working dev-lang/spidermonkey:68 on ia64. > > Émeric I forgot to say these patches apply cleanly against =dev-lang/spidermonkey-68.12.0 currently in portage tree. Please apply. Thanks, Émeric
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66118dc9fd89ce367c32928fefd979d0540f2150 commit 66118dc9fd89ce367c32928fefd979d0540f2150 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2020-10-20 14:09:22 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2020-10-20 14:26:12 +0000 dev-lang/spidermonkey: re-add ia64 JIT patches Bug: https://bugs.gentoo.org/703538 Package-Manager: Portage-3.0.8, Repoman-3.0.2 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> dev-lang/spidermonkey/Manifest | 2 +- dev-lang/spidermonkey/spidermonkey-68.12.0.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
Also added to 78.4.0.
(In reply to Thomas Deutschmann from comment #22) > Also added to 78.4.0. Thanks. But wouldn't it be better to centralize them in FIREFOX_PATCHSET (where they used to be, IIRC) rather than SPIDERMONKEY_PATCHSET? So that www-client/firefox, mail-client/thunderbird and dev-lang/spidermonkey can all leverage these patches. Though I recognize that virtual/rust depend is a blocker for modern www-client/firefox and mail-client/thunderbird on ia64 :-(
Sure, when you show us a build.log that this is triggered when building firefox, we will move the patch.
