head	1.1;
access;
symbols
	pkgsrc-2026Q1:1.1.0.64
	pkgsrc-2026Q1-base:1.1
	pkgsrc-2025Q4:1.1.0.62
	pkgsrc-2025Q4-base:1.1
	pkgsrc-2025Q3:1.1.0.60
	pkgsrc-2025Q3-base:1.1
	pkgsrc-2025Q2:1.1.0.58
	pkgsrc-2025Q2-base:1.1
	pkgsrc-2025Q1:1.1.0.56
	pkgsrc-2025Q1-base:1.1
	pkgsrc-2024Q4:1.1.0.54
	pkgsrc-2024Q4-base:1.1
	pkgsrc-2024Q3:1.1.0.52
	pkgsrc-2024Q3-base:1.1
	pkgsrc-2024Q2:1.1.0.50
	pkgsrc-2024Q2-base:1.1
	pkgsrc-2024Q1:1.1.0.48
	pkgsrc-2024Q1-base:1.1
	pkgsrc-2023Q4:1.1.0.46
	pkgsrc-2023Q4-base:1.1
	pkgsrc-2023Q3:1.1.0.44
	pkgsrc-2023Q3-base:1.1
	pkgsrc-2023Q2:1.1.0.42
	pkgsrc-2023Q2-base:1.1
	pkgsrc-2023Q1:1.1.0.40
	pkgsrc-2023Q1-base:1.1
	pkgsrc-2022Q4:1.1.0.38
	pkgsrc-2022Q4-base:1.1
	pkgsrc-2022Q3:1.1.0.36
	pkgsrc-2022Q3-base:1.1
	pkgsrc-2022Q2:1.1.0.34
	pkgsrc-2022Q2-base:1.1
	pkgsrc-2022Q1:1.1.0.32
	pkgsrc-2022Q1-base:1.1
	pkgsrc-2021Q4:1.1.0.30
	pkgsrc-2021Q4-base:1.1
	pkgsrc-2021Q3:1.1.0.28
	pkgsrc-2021Q3-base:1.1
	pkgsrc-2021Q2:1.1.0.26
	pkgsrc-2021Q2-base:1.1
	pkgsrc-2021Q1:1.1.0.24
	pkgsrc-2021Q1-base:1.1
	pkgsrc-2020Q4:1.1.0.22
	pkgsrc-2020Q4-base:1.1
	pkgsrc-2020Q3:1.1.0.20
	pkgsrc-2020Q3-base:1.1
	pkgsrc-2020Q2:1.1.0.18
	pkgsrc-2020Q2-base:1.1
	pkgsrc-2020Q1:1.1.0.14
	pkgsrc-2020Q1-base:1.1
	pkgsrc-2019Q4:1.1.0.16
	pkgsrc-2019Q4-base:1.1
	pkgsrc-2019Q3:1.1.0.12
	pkgsrc-2019Q3-base:1.1
	pkgsrc-2019Q2:1.1.0.10
	pkgsrc-2019Q2-base:1.1
	pkgsrc-2019Q1:1.1.0.8
	pkgsrc-2019Q1-base:1.1
	pkgsrc-2018Q4:1.1.0.6
	pkgsrc-2018Q4-base:1.1
	pkgsrc-2018Q3:1.1.0.4
	pkgsrc-2018Q3-base:1.1
	pkgsrc-2018Q2:1.1.0.2
	pkgsrc-2018Q2-base:1.1;
locks; strict;
comment	@// @;


1.1
date	2018.05.02.12.42.51;	author jperkin;	state Exp;
branches;
next	;
commitid	c6Ouwv7Es2pvJIAA;


desc
@@


1.1
log
@spidermonkey185: Fix SunOS/x86_64 mmap handling.

The previous MAP_32BIT workaround was insufficient, SpiderMonkey still makes
certain assumptions about memory layout, requiring that the high 17 bits are
clear.  This was most noticeable with couchdb's couchjs process that would
reliably segfault.

Instead, apply a mixture of Debian and upstream patches to implement their
ia64 workaround on SunOS/x86_64, utilising both a fixed mmap range and
disabling static strings to workaround this issue.

Tested with the couchdb test suite which now runs to completion.

Bump PKGREVISION.
@
text
@$NetBSD$

Implement Debian disable-static-strings-on-ia64.patch fix.

--- jsstr.cpp.orig	2011-03-31 19:08:36.000000000 +0000
+++ jsstr.cpp
@@@@ -3121,6 +3121,8 @@@@ static JSFunctionSpec string_methods[] =
     JS_FS_END
 };
 
+#ifdef JS_HAS_STATIC_STRINGS
+
 /*
  * Set up some tools to make it easier to generate large tables. After constant
  * folding, for each n, Rn(0) is the comma-separated list R(0), R(1), ..., R(2^n-1).
@@@@ -3291,6 +3293,8 @@@@ const JSString *const JSString::intStrin
 #undef R3
 #undef R7
 
+#endif  /* defined(JS_HAS_STATIC_STRINGS) */
+
 JSBool
 js_String(JSContext *cx, uintN argc, Value *vp)
 {
@@@@ -3331,6 +3335,7 @@@@ str_fromCharCode(JSContext *cx, uintN ar
         uint16_t code;
         if (!ValueToUint16(cx, argv[0], &code))
             return JS_FALSE;
+#ifdef JS_HAS_STATIC_STRINGS
         if (code < UNIT_STRING_LIMIT) {
             str = JSString::unitString(code);
             if (!str)
@@@@ -3338,6 +3343,7 @@@@ str_fromCharCode(JSContext *cx, uintN ar
             vp->setString(str);
             return JS_TRUE;
         }
+#endif
         argv[0].setInt32(code);
     }
     chars = (jschar *) cx->malloc((argc + 1) * sizeof(jschar));
@@@@ -3367,8 +3373,10 @@@@ String_fromCharCode(JSContext* cx, int32
 {
     JS_ASSERT(JS_ON_TRACE(cx));
     jschar c = (jschar)i;
+#ifdef JS_HAS_STATIC_STRINGS
     if (c < UNIT_STRING_LIMIT)
         return JSString::unitString(c);
+#endif
     return js_NewStringCopyN(cx, &c, 1);
 }
 #endif
@