kumquat-buildroot/package/spidermonkey/0008-save-and-restore-non-volatile-x28-on-ARM64-for-generated-unboxed-obje.patch

67 lines
2.5 KiB
Diff
Raw Normal View History

package/spidermonkey: new package 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>
2019-11-25 18:50:28 +01:00
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