wuggy/Dactyloidae
wuggy/Dactyloidae
1
0
Fork 0
mirror of https://repo.dactyloidae.xyz/Dactyloidae/UXP.git synced 2026-09-07 00:08:39 +09:00
Code Issues Projects Releases Packages Wiki Activity

MoonchildProductions#1251 - Part 23: Allow AMD64 build to work.

Browse source 
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Compiling_32-bit_Firefox_on_a_Linux_64-bit_OS

Setting this up turned out to be easier than I thought it would be. All I had to do was apply these instructions in reverse and add the following to my .mozconfig file:

CC="gcc -m64"
CXX="g++ -m64"
AS="gas --64"
ac_add_options --target=x86_64-pc-solaris2.11
export PKG_CONFIG_PATH=/usr/lib/amd64/pkgconfig
ac_add_options --libdir=/usr/lib/amd64
ac_add_options --x-libraries=/usr/lib/amd64

Most of these changes were fairly trivial, just requiring me to make a few of the changes I made earlier conditional on a 32-bit build. The biggest challenge was figuring out why the JavaScript engine triggered a segfault everytime it tried to allocate memory. But this patch fixes it:

https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/web/firefox/patches/patch-js_src_gc_Memory.cpp.patch

Turns out that Solaris on AMD64 handles memory management in a fairly unusual way with a segmented memory model, but it's not that different from what we see on other 64-bit processors. In fact, I saw a SPARC crash for a similar reason, and noticed that it looked just like mine except the numbers in the first segment were reversed. Having played around with hex editors before, I had a feeling I might be dealing with a little-endian version of a big-endian problem, but I didn't expect that knowledge to actually yield an easy solution.

https://bugzilla.mozilla.org/show_bug.cgi?id=577056

https://www.oracle.com/technetwork/server-storage/solaris10/solaris-memory-135224.html

As far as I can tell, this was the last barrier to an AMD64 Solaris build of Pale Moon.
This commit is contained in:
athenian200 2019-10-10 15:38:27 -05:00 • committed by Roy Tam
commit 0239eb8ac9
8 changed files with 102 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

11
js/src/gc/Memory.cpp
View file

@ -415,8 +415,15 @@ InitMemorySubsystem()
static inline void*
MapMemoryAt(void* desired, size_t length, int prot = PROT_READ | PROT_WRITE,
int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset = 0)
// Solaris manages 64-bit address space in a different manner from every other
// AMD64 operating system, but fortunately the fix is the same one
// required for every operating system on 64-bit SPARC, Itanium, and ARM.
// Most people's intuition failed them here and they thought this couldn't
// possibly be correct on AMD64, but for Solaris/illumos it is.
{
#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || defined(__aarch64__)
#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || defined(__aarch64__) || (defined(__sun) && defined(__x86_64__))
MOZ_ASSERT((0xffff800000000000ULL & (uintptr_t(desired) + length - 1)) == 0);
#endif
void* region = mmap(desired, length, prot, flags, fd, offset);
@ -466,7 +473,7 @@ MapMemory(size_t length, int prot = PROT_READ | PROT_WRITE,
return nullptr;
}
return region;
#elif defined(__aarch64__)
#elif defined(__aarch64__) || (defined(__sun) && defined(__x86_64__))
/*
* There might be similar virtual address issue on arm64 which depends on
* hardware and kernel configurations. But the work around is slightly