335c0bc610
Spidermonkey is Mozilla's JavaScript engine written in C and C++. It is used in
various Mozilla products, including Firefox, and is available under the MPL2.
There are 10 patches currently required to properly cross-compile spidermonkey:
1) allow-newer-autoconf-versions
- Spidermonkey is hardcoded to use Autoconf 2.13, which is from 1999!
The reasoning behind using 2.13 is because newer versions of Autoconf do not
work correctly with the custom m4 macros in the source code.
However: Because we are building just the Spidermonkey engine instead of the
entire Firefox package, newer versions of Autoconf work without issue.
See: See: https://bugzilla.mozilla.org/show_bug.cgi?id=104642
for further explanation.
2) allow-building-in-tree
- By default, spidermonkey must be configured and built out-of-tree, otherwise
the following error occurs:
FATAL ERROR PROCESSING MOZBUILD FILE
==============================
The error occurred while processing the following file or one of the files
it includes:
js/src/shell/moz.build
The error occurred when validating the result of the execution. The reported
error is:
The path specified in LOCAL_INCLUDES is not allowed:
.. (resolved to js/src)
Remove this check, as spidermonkey builds without issue in-tree.
3) allow-unknown-configuration-options
- By default, if an unknown parameter is passed to configure, an error is
raised. Replace the raise with a pass and continue.
Fixes: https://bugzilla.mozilla.org/show_bug.cgi?id=1379540
4) fix-building-with-musl
- The MIPS specific header <sgidefs.h> is not provided by musl.
The Linux kernel headers <asm/sgidefs.h> provide the same definitions.
5) add-riscv-support
- Submitted upstream:
See: https://bugzilla.mozilla.org/show_bug.cgi?id=1318905
6) copy-headers-on-install-instead-of-symlinking
- When installing, instead of linking the headers to the source directory,
copy them.
7) ensure-proper-running-on-64-bit-and-32-bit-be-platforms
- Taken from the Fedora RPM
Applied upstream.
Fixes: https://bugzilla.mozilla.org/show_bug.cgi?id=1488552
8) 0008-save-and-restore-non-volatile-x28-on-ARM64-for-generated-unboxed-obje
- Taken from the Fedora RPM:
Applied upstream.
Fixes: https://bugzilla.mozilla.org/show_bug.cgi?id=1375074
9) save-x28-before-clobbering-it-in-the-regex-compiler
- Taken from the Fedora RPM:
Applied upstream.
Fixes: https://bugzilla.mozilla.org/show_bug.cgi?id=1445907
10) always-use-the-equivalent-year-to-determine-the-time-zone
- Taken from the Fedora RPM:
Applied upstream.
Fixes: https://bugzilla.mozilla.org/show_bug.cgi?id=1415202
Typically, The Firefox source tarball is used to build spidermonkey; however,
this has two disadvantages:
- It's large. The Firefox source tarball is over 250M.
- It requires Autoconf 2.13
Instead, use a tarball with only the Spidermonkey source code in it with a
pre-setup configure file. This tarball reduces the size to 31M and prevents the
Autoconf 2.13 requirement.
Signed-off-by: Adam Duskett <aduskett@greenlots.com>
[Thomas: adjust how the libnspr arch dependency is handled]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
67 lines
2.5 KiB
Diff
67 lines
2.5 KiB
Diff
From 903a79a1efff18fc7cc50db09a3fe5d768adc9a8 Mon 19 Mar 2018 09:58:06 +0100
|
|
From: Lars T Hansen <lhansen@mozilla.com>
|
|
Date: Fri, 23 Mar 2018 22:01:33 +0000
|
|
Subject: [PATCH] save and restore non-volatile x28 on ARM64 for generated unboxed object constructor
|
|
|
|
Fixes: https://bugzilla.mozilla.org/show_bug.cgi?id=1375074
|
|
|
|
Upsream-status: Applied
|
|
See: https://hg.mozilla.org/mozilla-central/rev/800abe66894d
|
|
|
|
Signed-off-by: Lars T Hansen <lhansen@mozilla.com>
|
|
Signed-off-by: Adam Duskett <aduskett@gmail.com>
|
|
---
|
|
js/src/vm/UnboxedObject.cpp | 30 ++++++++++++++++++++++++++----
|
|
1 file changed, 26 insertions(+), 4 deletions(-)
|
|
|
|
diff --git a/js/src/vm/UnboxedObject.cpp b/js/src/vm/UnboxedObject.cpp
|
|
index 35ca20d7405f..1c20a1093d13 100644
|
|
--- a/js/src/vm/UnboxedObject.cpp
|
|
+++ b/js/src/vm/UnboxedObject.cpp
|
|
@@ -86,9 +86,16 @@ static const uintptr_t CLEAR_CONSTRUCTOR_CODE_TOKEN = 0x1;
|
|
#endif
|
|
|
|
#ifdef JS_CODEGEN_ARM64
|
|
- // ARM64 communicates stack address via sp, but uses a pseudo-sp for
|
|
- // addressing.
|
|
- masm.initStackPtr();
|
|
+ // ARM64 communicates stack address via sp, but uses a pseudo-sp (PSP) for
|
|
+ // addressing. The register we use for PSP may however also be used by
|
|
+ // calling code, and it is nonvolatile, so save it. Do this as a special
|
|
+ // case first because the generic save/restore code needs the PSP to be
|
|
+ // initialized already.
|
|
+ MOZ_ASSERT(PseudoStackPointer64.Is(masm.GetStackPointer64()));
|
|
+ masm.Str(PseudoStackPointer64, vixl::MemOperand(sp, -16, vixl::PreIndex));
|
|
+
|
|
+ // Initialize the PSP from the SP.
|
|
+ masm.initStackPtr();
|
|
#endif
|
|
|
|
MOZ_ASSERT(propertiesReg.volatile_());
|
|
@@ -239,7 +246,22 @@ static const uintptr_t CLEAR_CONSTRUCTOR_CODE_TOKEN = 0x1;
|
|
if (ScratchDoubleReg.volatile_()) masm.pop(ScratchDoubleReg);
|
|
masm.PopRegsInMask(savedNonVolatileRegisters);
|
|
|
|
- masm.abiret();
|
|
+#ifdef JS_CODEGEN_ARM64
|
|
+ // Now restore the value that was in the PSP register on entry, and return.
|
|
+
|
|
+ // Obtain the correct SP from the PSP.
|
|
+ masm.Mov(sp, PseudoStackPointer64);
|
|
+
|
|
+ // Restore the saved value of the PSP register, this value is whatever the
|
|
+ // caller had saved in it, not any actual SP value, and it must not be
|
|
+ // overwritten subsequently.
|
|
+ masm.Ldr(PseudoStackPointer64, vixl::MemOperand(sp, 16, vixl::PostIndex));
|
|
+
|
|
+ // Perform a plain Ret(), as abiret() will move SP <- PSP and that is wrong.
|
|
+ masm.Ret(vixl::lr);
|
|
+#else
|
|
+ masm.abiret();
|
|
+#endif
|
|
|
|
masm.bind(&failureStoreOther);
|
|
|
|
--
|
|
2.23.0
|