From 64e03d0149bed895d00e20e71da775e2aabf2f81 Mon Sep 17 00:00:00 2001 From: athenian200 Date: Tue, 1 Oct 2019 07:26:40 -0500 Subject: MoonchildProductions#1251 - Part 3: Finally end the long tradition of casting getpid() to int. https://bugzilla.mozilla.org/show_bug.cgi?id=535106 https://bugzilla.mozilla.org/show_bug.cgi?id=1359841 Like many parts of the busted Solaris support, this one has its origins in the pre-Firefox days. Bug 535106, another Mozilla suite bug. It keeps coming up because the core issue is never addressed, the fact that nsTSubstring doesn't know how to handle pid_t. I think the explicit cast to int is a band-aid they use because they know if they touch that substring header file to make it handle pid_t, they'll probably be asked to fix all the other problems with it. I honestly think it just works by accident on other platforms because it's implicitly cast to signed or unsigned int, even though the POSIX standard says pid_t can be either long or int, and work as either a signed or unsigned integer. Whatever the case may be, it's handled better on Solaris now than it was. Ironically enough, the main point of having pid_t rather than just having pids be int or something is to hide this little implementation detail so you can just use pid_t for the return type in portable code without having to worry about what it is on a specific platform. The unfortunate way Mozilla implemented string functions turns that on its head and makes the good things about pid_t into liabilities rather than assets. --- xpcom/string/nsTSubstring.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'xpcom/string') diff --git a/xpcom/string/nsTSubstring.h b/xpcom/string/nsTSubstring.h index 53b4fb9a8..2b0723c04 100644 --- a/xpcom/string/nsTSubstring.h +++ b/xpcom/string/nsTSubstring.h @@ -9,6 +9,9 @@ #include "mozilla/MemoryReporting.h" #include "mozilla/IntegerTypeTraits.h" #include "mozilla/Span.h" +#ifdef XP_SOLARIS +#include +#endif #ifndef MOZILLA_INTERNAL_API #error Cannot use internal string classes without MOZILLA_INTERNAL_API defined. Use the frozen header nsStringAPI.h instead. @@ -587,6 +590,17 @@ public: const char* fmt = aRadix == 10 ? "%d" : aRadix == 8 ? "%o" : "%x"; AppendPrintf(fmt, aInteger); } +#ifdef XP_SOLARIS + void AppendInt(pid_t aInteger) + { + AppendPrintf("%lu", aInteger); + } + void AppendInt(pid_t aInteger, int aRadix) + { + const char* fmt = aRadix == 10 ? "%lu" : aRadix == 8 ? "%lo" : "%lx"; + AppendPrintf(fmt, aInteger); + } +#endif void AppendInt(uint32_t aInteger) { AppendPrintf("%u", aInteger); -- cgit v1.2.3 From 2f4488521db663520c703a9a836d5549d679266c Mon Sep 17 00:00:00 2001 From: athenian200 Date: Thu, 10 Oct 2019 15:38:27 -0500 Subject: MoonchildProductions#1251 - Part 23: Allow AMD64 build to work. 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. --- xpcom/string/nsTSubstring.h | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'xpcom/string') diff --git a/xpcom/string/nsTSubstring.h b/xpcom/string/nsTSubstring.h index 2b0723c04..537889d5c 100644 --- a/xpcom/string/nsTSubstring.h +++ b/xpcom/string/nsTSubstring.h @@ -9,7 +9,12 @@ #include "mozilla/MemoryReporting.h" #include "mozilla/IntegerTypeTraits.h" #include "mozilla/Span.h" -#ifdef XP_SOLARIS + +// Solaris defines pid_t to be long on ILP32 and int on LP64. I checked in +// sys/types.h. AMD64 and SPARC64 builds don't need this fix at all, +// while all 32-bit builds do. + +#if defined(XP_SOLARIS) && !defined(__LP64__) #include #endif @@ -590,7 +595,7 @@ public: const char* fmt = aRadix == 10 ? "%d" : aRadix == 8 ? "%o" : "%x"; AppendPrintf(fmt, aInteger); } -#ifdef XP_SOLARIS +#if defined(XP_SOLARIS) && !defined(__LP64__) void AppendInt(pid_t aInteger) { AppendPrintf("%lu", aInteger); -- cgit v1.2.3