Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 703538 - >dev-lang/spidermonkey-45.0.2 broken on ia64
Summary: >dev-lang/spidermonkey-45.0.2 broken on ia64
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: IA64 Linux
: Normal normal (vote)
Assignee: Mozilla Gentoo Team
URL: https://bugzilla.mozilla.org/show_bug...
Whiteboard:
Keywords: PATCH, REGRESSION
Depends on:
Blocks: 685150 701052 701054
  Show dependency tree
 
Reported: 2019-12-22 14:20 UTC by Émeric Maschino
Modified: 2020-10-21 14:32 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (spidermonkey-60.5.2_p0-r2:20191230-142304.log.bz2,66.25 KB, application/x-bzip)
2019-12-30 14:44 UTC, Agostino Sarubbo
Details
spidermonkey-60.5.2_p0-ia64-jit.patch (spidermonkey-60.5.2_p0-ia64-jit.patch,646 bytes, patch)
2020-01-15 23:43 UTC, Sergei Trofimovich (RETIRED)
Details | Diff
0001-ProcessExecutableMemory.cpp-fix-virtual-address-leng.patch (0001-ProcessExecutableMemory.cpp-fix-virtual-address-leng.patch,2.49 KB, patch)
2020-01-24 00:12 UTC, Sergei Trofimovich (RETIRED)
Details | Diff
dev-lang/spidermonkey:68 Add JIT ia64 atomics (spidermonkey-68.12.0-jit-ia64-atomics.patch,769 bytes, patch)
2020-10-17 15:01 UTC, Émeric Maschino
Details | Diff
dev-lang/spidermonkey:68 JIT Fix virtual address length on ia64 (spidermonkey-68.12.0-jit-fix-virtual-address-length-on-ia64.patch,2.33 KB, patch)
2020-10-17 15:03 UTC, Émeric Maschino
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Émeric Maschino 2019-12-22 14:20:03 UTC
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
Comment 1 Émeric Maschino 2019-12-22 14:20:41 UTC
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
Comment 2 Agostino Sarubbo gentoo-dev 2019-12-30 14:44:35 UTC
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
Comment 3 Émeric Maschino 2020-01-05 14:15:54 UTC
(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.
Comment 4 Émeric Maschino 2020-01-15 21:32:34 UTC
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
Comment 5 Émeric Maschino 2020-01-15 21:55:07 UTC
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?
Comment 6 Sergei Trofimovich (RETIRED) gentoo-dev 2020-01-15 23:43:46 UTC
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.
Comment 7 Sergei Trofimovich (RETIRED) gentoo-dev 2020-01-15 23:46:02 UTC
(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.
Comment 8 Émeric Maschino 2020-01-16 23:01:07 UTC
(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?
Comment 9 Jory A. Pratt gentoo-dev 2020-01-17 02:42:11 UTC
(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.
Comment 10 Sergei Trofimovich (RETIRED) gentoo-dev 2020-01-23 07:49:18 UTC
(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.
Comment 11 Sergei Trofimovich (RETIRED) gentoo-dev 2020-01-24 00:12:35 UTC
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.
Comment 12 Émeric Maschino 2020-01-27 21:43:23 UTC
(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
Comment 13 Émeric Maschino 2020-04-21 10:07:06 UTC
(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
Comment 14 Larry the Git Cow gentoo-dev 2020-04-21 11:50:37 UTC
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(+)
Comment 15 Thomas Deutschmann gentoo-dev Security 2020-04-21 11:51:24 UTC
Could you please also give spidermonkey-68.7.0+ a try on ia64?
Comment 16 Émeric Maschino 2020-04-21 16:58:31 UTC
(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+?
Comment 17 Émeric Maschino 2020-10-17 15:01:51 UTC
Created attachment 666236 [details, diff]
dev-lang/spidermonkey:68 Add JIT ia64 atomics
Comment 18 Émeric Maschino 2020-10-17 15:03:13 UTC
Created attachment 666239 [details, diff]
dev-lang/spidermonkey:68 JIT Fix virtual address length on ia64
Comment 19 Émeric Maschino 2020-10-17 15:06:43 UTC
(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
Comment 20 Émeric Maschino 2020-10-17 15:08:57 UTC
(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
Comment 21 Larry the Git Cow gentoo-dev 2020-10-20 14:26:18 UTC
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(-)
Comment 22 Thomas Deutschmann gentoo-dev Security 2020-10-20 14:26:45 UTC
Also added to 78.4.0.
Comment 23 Émeric Maschino 2020-10-21 14:18:25 UTC
(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 :-(
Comment 24 Thomas Deutschmann gentoo-dev Security 2020-10-21 14:32:46 UTC
Sure, when you show us a build.log that this is triggered when building firefox, we will move the patch.