Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions

2018-05-11 Thread Mike Hommey 
On Fri, May 11, 2018 at 08:49:41PM +0200, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> With Firefox 60.0 ESR now in experimental, most of the sparc64-related patches
> are now part of the upstream source.
> 
> The only patches we actually need are the one to fix skia on big-endian 
> targets
> (I am currently in the process of upstreaming this one) and one tiny patch
> to fix an alignment issue on sparc64.

For the record, the latter was explicitly rejected.

Mike

Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions

2018-05-11 Thread John Paul Adrian Glaubitz 
On 05/11/2018 11:20 PM, Mike Hommey wrote:
>> The only patches we actually need are the one to fix skia on big-endian 
>> targets
>> (I am currently in the process of upstreaming this one) and one tiny patch
>> to fix an alignment issue on sparc64.
> 
> For the record, the latter was explicitly rejected.

I know. However, the person who wrote it is a security expert (and a friend of
mine) and I trust him when he says the patch does not change any behavior or
lower the security.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions

2018-05-11 Thread John Paul Adrian Glaubitz 

Hi!

With Firefox 60.0 ESR now in experimental, most of the sparc64-related patches
are now part of the upstream source.

The only patches we actually need are the one to fix skia on big-endian targets
(I am currently in the process of upstreaming this one) and one tiny patch
to fix an alignment issue on sparc64.

Attaching both of them. The skia patch will also fix the build on s390x.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -r ee1d1bf1dc8a gfx/skia/skia/include/core/SkColorPriv.h
--- a/gfx/skia/skia/include/core/SkColorPriv.h	Thu Apr 12 03:35:11 2018 -0700
+++ b/gfx/skia/skia/include/core/SkColorPriv.h	Fri Apr 13 10:04:36 2018 +0300
@@ -55,17 +55,10 @@
  *  Here we enforce this constraint.
  */
 
-#ifdef SK_CPU_BENDIAN
-#define SK_RGBA_R32_SHIFT   24
-#define SK_RGBA_G32_SHIFT   16
-#define SK_RGBA_B32_SHIFT   8
-#define SK_RGBA_A32_SHIFT   0
-#else
-#define SK_RGBA_R32_SHIFT   0
-#define SK_RGBA_G32_SHIFT   8
-#define SK_RGBA_B32_SHIFT   16
-#define SK_RGBA_A32_SHIFT   24
-#endif
+#define SK_RGBA_R32_SHIFT   0
+#define SK_RGBA_G32_SHIFT   8
+#define SK_RGBA_B32_SHIFT   16
+#define SK_RGBA_A32_SHIFT   24
 
 #define SkGetPackedA32(packed)  ((uint32_t)((packed) << (24 - SK_A32_SHIFT)) >> 24)
 #define SkGetPackedR32(packed)  ((uint32_t)((packed) << (24 - SK_R32_SHIFT)) >> 24)
diff -r ee1d1bf1dc8a gfx/skia/skia/include/core/SkImageInfo.h
--- a/gfx/skia/skia/include/core/SkImageInfo.h	Thu Apr 12 03:35:11 2018 -0700
+++ b/gfx/skia/skia/include/core/SkImageInfo.h	Fri Apr 13 10:04:36 2018 +0300
@@ -84,7 +84,7 @@
 #elif SK_PMCOLOR_BYTE_ORDER(R,G,B,A)
 kN32_SkColorType = kRGBA__SkColorType,
 #else
-#error "SK_*32_SHIFT values must correspond to BGRA or RGBA byte order"
+kN32_SkColorType = kBGRA__SkColorType
 #endif
 };
 
diff -r ee1d1bf1dc8a gfx/skia/skia/include/gpu/GrTypes.h
--- a/gfx/skia/skia/include/gpu/GrTypes.h	Thu Apr 12 03:35:11 2018 -0700
+++ b/gfx/skia/skia/include/gpu/GrTypes.h	Fri Apr 13 10:04:36 2018 +0300
@@ -344,15 +344,13 @@
 static const int kGrPixelConfigCnt = kLast_GrPixelConfig + 1;
 
 // Aliases for pixel configs that match skia's byte order.
-#ifndef SK_CPU_LENDIAN
-#error "Skia gpu currently assumes little endian"
-#endif
 #if SK_PMCOLOR_BYTE_ORDER(B,G,R,A)
 static const GrPixelConfig kSkia_GrPixelConfig = kBGRA__GrPixelConfig;
 #elif SK_PMCOLOR_BYTE_ORDER(R,G,B,A)
 static const GrPixelConfig kSkia_GrPixelConfig = kRGBA__GrPixelConfig;
 #else
-#error "SK_*32_SHIFT values must correspond to GL_BGRA or GL_RGBA format."
+static const GrPixelConfig kSkia_GrPixelConfig = kBGRA__GrPixelConfig;
+static const GrPixelConfig kSkiaGamma_GrPixelConfig = kSBGRA__GrPixelConfig;
 #endif
 
 /**
diff -r ee1d1bf1dc8a gfx/skia/skia/include/private/GrColor.h
--- a/gfx/skia/skia/include/private/GrColor.h	Thu Apr 12 03:35:11 2018 -0700
+++ b/gfx/skia/skia/include/private/GrColor.h	Fri Apr 13 10:04:36 2018 +0300
@@ -74,7 +74,11 @@
  *  Since premultiplied means that alpha >= color, we construct a color with
  *  each component==255 and alpha == 0 to be "illegal"
  */
+#ifdef SK_CPU_BENDIAN
+#define GrColor_ILLEGAL 0xFF00
+#else
 #define GrColor_ILLEGAL (~(0xFF << GrColor_SHIFT_A))
+#endif
 
 #define GrColor_WHITE 0x
 #define GrColor_TRANSPARENT_BLACK 0x0
diff -r ee1d1bf1dc8a gfx/skia/skia/src/core/SkColorData.h
--- a/gfx/skia/skia/src/core/SkColorData.h	Thu Apr 12 03:35:11 2018 -0700
+++ b/gfx/skia/skia/src/core/SkColorData.h	Fri Apr 13 10:04:36 2018 +0300
@@ -32,17 +32,10 @@
  *  Here we enforce this constraint.
  */
 
-#ifdef SK_CPU_BENDIAN
-#define SK_BGRA_B32_SHIFT   24
-#define SK_BGRA_G32_SHIFT   16
-#define SK_BGRA_R32_SHIFT   8
-#define SK_BGRA_A32_SHIFT   0
-#else
-#define SK_BGRA_B32_SHIFT   0
-#define SK_BGRA_G32_SHIFT   8
-#define SK_BGRA_R32_SHIFT   16
-#define SK_BGRA_A32_SHIFT   24
-#endif
+#define SK_BGRA_B32_SHIFT   0
+#define SK_BGRA_G32_SHIFT   8
+#define SK_BGRA_R32_SHIFT   16
+#define SK_BGRA_A32_SHIFT   24
 
 #if defined(SK_PMCOLOR_IS_RGBA) && defined(SK_PMCOLOR_IS_BGRA)
 #error "can't define PMCOLOR to be RGBA and BGRA"
>From 334b650e843cb307397fd627814421873131f0ed Mon Sep 17 00:00:00 2001
From: Michael Karcher 
Date: Thu, 1 Feb 2018 00:04:36 +0100
Subject: [PATCH] Bug 1434726 - Early startup crash on Linux sparc64 in
 HashIIDPtrKey

---
 js/xpconnect/src/XPCMaps.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/js/xpconnect/src/XPCMaps.cpp b/js/xpconnect/src/XPCMaps.cpp
index bb99b9f8c034..837d5d78970f 100644
--- a/js/xpconnect/src/XPCMaps.cpp
+++ b/js/xpconnect/src/XPCMaps.cpp
@@ -23,7 +23,7 @@ using namespace mozilla;
 static PLDHashNumber
 HashIIDPtrKey(const void* key)
 {
-

Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions

2017-06-18 Thread John Paul Adrian Glaubitz 
Control: reassign -1 firefox-esr

Hello!

Since the latest firefox package requires rustc now which isn't available on
sparc64 yet, I have ported the sparc64 support patch to the firefox-esr
package. I am attaching the updated patch.

Could it be applied for the next upload, please? The patch is merely a backport
of all the missing sparc64 fixes that got merged upstream, so they have all
been positively reviewed by Mozilla upstream.

Thank you very much!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Description: Add support for sparc64
Author: John Paul Adrian Glaubitz 
Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1275204
Last-Update: 2017-06-18

Index: firefox-esr-52.2.0esr/ipc/chromium/src/build/build_config.h
===
--- firefox-esr-52.2.0esr.orig/ipc/chromium/src/build/build_config.h
+++ firefox-esr-52.2.0esr/ipc/chromium/src/build/build_config.h
@@ -83,7 +83,7 @@
 #elif defined(__ppc__) || defined(__powerpc__)
 #define ARCH_CPU_PPC 1
 #define ARCH_CPU_32_BITS 1
-#elif defined(__sparc64__)
+#elif defined(__sparc__) && defined(__arch64__)
 #define ARCH_CPU_SPARC 1
 #define ARCH_CPU_64_BITS 1
 #elif defined(__sparc__)
Index: firefox-esr-52.2.0esr/js/src/gc/Memory.cpp
===
--- firefox-esr-52.2.0esr.orig/js/src/gc/Memory.cpp
+++ firefox-esr-52.2.0esr/js/src/gc/Memory.cpp
@@ -501,7 +501,7 @@ 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)
 {
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || defined(__aarch64__)
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && (defined(__NetBSD__) || defined(__linux__)))
 MOZ_ASSERT((0x8000ULL & (uintptr_t(desired) + length - 1)) == 0);
 #endif
 void* region = mmap(desired, length, prot, flags, fd, offset);
@@ -524,7 +524,7 @@ static inline void*
 MapMemory(size_t length, int prot = PROT_READ | PROT_WRITE,
   int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset = 0)
 {
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__))
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && defined(__NetBSD__))
 /*
  * The JS engine assumes that all allocated pointers have their high 17 bits clear,
  * which ia64's mmap doesn't support directly. However, we can emulate it by passing
@@ -551,7 +551,7 @@ MapMemory(size_t length, int prot = PROT
 return nullptr;
 }
 return region;
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) || (defined(__sparc__) && defined(__arch64__) && defined(__linux__))
/*
 * There might be similar virtual address issue on arm64 which depends on
 * hardware and kernel configurations. But the work around is slightly
Index: firefox-esr-52.2.0esr/js/src/jsapi-tests/testGCAllocator.cpp
===
--- firefox-esr-52.2.0esr.orig/js/src/jsapi-tests/testGCAllocator.cpp
+++ firefox-esr-52.2.0esr/js/src/jsapi-tests/testGCAllocator.cpp
@@ -312,7 +312,7 @@ void unmapPages(void* p, size_t size) {
 void*
 mapMemoryAt(void* desired, size_t length)
 {
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || defined(__aarch64__)
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && (defined(__NetBSD__) || defined(__linux__)))
 MOZ_RELEASE_ASSERT(0x8000ULL & (uintptr_t(desired) + length - 1) == 0);
 #endif
 void* region = mmap(desired, length, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
@@ -334,7 +334,7 @@ mapMemory(size_t length)
 int fd = -1;
 off_t offset = 0;
 // The test code must be aligned with the implementation in gc/Memory.cpp.
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__))
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && defined(__NetBSD__))
 void* region = mmap((void*)0x0700, length, prot, flags, fd, offset);
 if (region == MAP_FAILED)
 return nullptr;
@@ -344,7 +344,7 @@ mapMemory(size_t length)
 return nullptr;
 }
 return region;
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) || (defined(__sparc__) && defined(__arch64__) && defined(__linux__))
 const uintptr_t start = UINT64_C(0x0700);
 const uintptr_t end   = UINT64_C(0x8000);
 const uintptr_t step  = js::gc::ChunkSize;
Index: firefox-esr-52.2.0esr/media/webrtc/trunk/build/build_config.h
===
---

Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions

2016-12-30 Thread John Paul Adrian Glaubitz 
Control: retitle -1 firefox: Fix broken sparc64 build support

Attaching an updated patch and retitled the bug report since this isn't
just platform definitions which are wrong but some more issues have to
be addressed.

Would be great to have this patch with the sparc64 as well as the m68k
build fixes [1] included in the next upload so the package gets fixed
on these two targets.

Further patches for alpha, hppa and sh4 are currently being worked on.

Thanks,
Adrian

> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849751

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Fix build on sparc64
Author: John Paul Adrian Glaubitz 
Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1275204
Last-Update: 2016-12-30

--- firefox-50.1.0.orig/image/decoders/nsIconDecoder.cpp
+++ firefox-50.1.0/image/decoders/nsIconDecoder.cpp
@@ -97,7 +97,8 @@ nsIconDecoder::ReadRowOfPixels(const cha
   return AsVariant(WriteState::NEED_MORE_DATA);  // Done with this row.
 }
 
-uint32_t pixel = *reinterpret_cast(aData);
+uint32_t pixel;
+memcpy(, aData, sizeof(pixel));
 aData += 4;
 aLength -= 4;
 
--- firefox-50.1.0.orig/ipc/chromium/src/build/build_config.h
+++ firefox-50.1.0/ipc/chromium/src/build/build_config.h
@@ -83,7 +83,7 @@
 #elif defined(__ppc__) || defined(__powerpc__)
 #define ARCH_CPU_PPC 1
 #define ARCH_CPU_32_BITS 1
-#elif defined(__sparc64__)
+#elif defined(__sparc__) && defined(__arch64__)
 #define ARCH_CPU_SPARC 1
 #define ARCH_CPU_64_BITS 1
 #elif defined(__sparc__)
--- firefox-50.1.0.orig/js/src/gc/Memory.cpp
+++ firefox-50.1.0/js/src/gc/Memory.cpp
@@ -490,7 +490,7 @@ 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)
 {
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || defined(__aarch64__)
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && (defined(__NetBSD__) || defined(__linux__))) || defined(__aarch64__)
 MOZ_ASSERT((0x8000ULL & (uintptr_t(desired) + length - 1)) == 0);
 #endif
 void* region = mmap(desired, length, prot, flags, fd, offset);
@@ -513,7 +513,7 @@ static inline void*
 MapMemory(size_t length, int prot = PROT_READ | PROT_WRITE,
   int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset = 0)
 {
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__))
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && defined(__NetBSD__))
 /*
  * The JS engine assumes that all allocated pointers have their high 17 bits clear,
  * which ia64's mmap doesn't support directly. However, we can emulate it by passing
@@ -540,7 +540,7 @@ MapMemory(size_t length, int prot = PROT
 return nullptr;
 }
 return region;
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) || (defined(__sparc__) && defined(__arch64__) && defined(__linux__))
/*
 * There might be similar virtual address issue on arm64 which depends on
 * hardware and kernel configurations. But the work around is slightly
--- firefox-50.1.0.orig/js/src/jsapi-tests/testGCAllocator.cpp
+++ firefox-50.1.0/js/src/jsapi-tests/testGCAllocator.cpp
@@ -312,7 +312,7 @@ void unmapPages(void* p, size_t size) {
 void*
 mapMemoryAt(void* desired, size_t length)
 {
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || defined(__aarch64__)
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && (defined(__NetBSD__) || defined(__linux__))) || defined(__aarch64__)
 MOZ_RELEASE_ASSERT(0x8000ULL & (uintptr_t(desired) + length - 1) == 0);
 #endif
 void* region = mmap(desired, length, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
@@ -334,7 +334,7 @@ mapMemory(size_t length)
 int fd = -1;
 off_t offset = 0;
 // The test code must be aligned with the implementation in gc/Memory.cpp.
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__))
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && defined(__NetBSD__))
 void* region = mmap((void*)0x0700, length, prot, flags, fd, offset);
 if (region == MAP_FAILED)
 return nullptr;
@@ -344,7 +344,7 @@ mapMemory(size_t length)
 return nullptr;
 }
 return region;
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) || (defined(__sparc__) && defined(__arch64__) && defined(__linux__))
 const uintptr_t start = UINT64_C(0x0700);
 const uintptr_t end   = UINT64_C(0x8000);
 const uintptr_t step  = js::gc::ChunkSize;
--- firefox-50.1.0.orig/media/webrtc/trunk/build/build_config.h
+++ firefox-50.1.0/media/webrtc/trunk/build/build_config.h
@@

Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions

2016-12-12 Thread John Paul Adrian Glaubitz 
Control: tags + patch

The attached patch fixes Firefox on sparc64 for me. The compiled binary
runs but crashes at some point with SIGBUS. This should be easy to debug
with gdb though. Will give a try later.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Add support for sparc64
Author: John Paul Adrian Glaubitz 
Date: 2016-12-12

Index: firefox-50.0.2/ipc/chromium/src/build/build_config.h
===
--- firefox-50.0.2.orig/ipc/chromium/src/build/build_config.h
+++ firefox-50.0.2/ipc/chromium/src/build/build_config.h
@@ -83,7 +83,7 @@
 #elif defined(__ppc__) || defined(__powerpc__)
 #define ARCH_CPU_PPC 1
 #define ARCH_CPU_32_BITS 1
-#elif defined(__sparc64__)
+#elif defined(__sparc__) && defined(__arch64__)
 #define ARCH_CPU_SPARC 1
 #define ARCH_CPU_64_BITS 1
 #elif defined(__sparc__)
Index: firefox-50.0.2/js/src/gc/Memory.cpp
===
--- firefox-50.0.2.orig/js/src/gc/Memory.cpp
+++ firefox-50.0.2/js/src/gc/Memory.cpp
@@ -490,7 +490,7 @@ 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)
 {
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || defined(__aarch64__)
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__)) || defined(__aarch64__)
 MOZ_ASSERT((0x8000ULL & (uintptr_t(desired) + length - 1)) == 0);
 #endif
 void* region = mmap(desired, length, prot, flags, fd, offset);
@@ -513,7 +513,7 @@ static inline void*
 MapMemory(size_t length, int prot = PROT_READ | PROT_WRITE,
   int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset = 0)
 {
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__))
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && defined(__NetBSD__))
 /*
  * The JS engine assumes that all allocated pointers have their high 17 bits clear,
  * which ia64's mmap doesn't support directly. However, we can emulate it by passing
@@ -540,7 +540,7 @@ MapMemory(size_t length, int prot = PROT
 return nullptr;
 }
 return region;
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) || (defined(__sparc__) && defined(__arch64__))
/*
 * There might be similar virtual address issue on arm64 which depends on
 * hardware and kernel configurations. But the work around is slightly
Index: firefox-50.0.2/js/src/jsapi-tests/testGCAllocator.cpp
===
--- firefox-50.0.2.orig/js/src/jsapi-tests/testGCAllocator.cpp
+++ firefox-50.0.2/js/src/jsapi-tests/testGCAllocator.cpp
@@ -312,7 +312,7 @@ void unmapPages(void* p, size_t size) {
 void*
 mapMemoryAt(void* desired, size_t length)
 {
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || defined(__aarch64__)
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__)) || defined(__aarch64__)
 MOZ_RELEASE_ASSERT(0x8000ULL & (uintptr_t(desired) + length - 1) == 0);
 #endif
 void* region = mmap(desired, length, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
@@ -334,7 +334,7 @@ mapMemory(size_t length)
 int fd = -1;
 off_t offset = 0;
 // The test code must be aligned with the implementation in gc/Memory.cpp.
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__))
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && defined(__NetBSD__))
 void* region = mmap((void*)0x0700, length, prot, flags, fd, offset);
 if (region == MAP_FAILED)
 return nullptr;
@@ -344,7 +344,7 @@ mapMemory(size_t length)
 return nullptr;
 }
 return region;
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) || (defined(__sparc__) && defined(__arch64__))
 const uintptr_t start = UINT64_C(0x0700);
 const uintptr_t end   = UINT64_C(0x8000);
 const uintptr_t step  = js::gc::ChunkSize;
Index: firefox-50.0.2/media/webrtc/trunk/build/build_config.h
===
--- firefox-50.0.2.orig/media/webrtc/trunk/build/build_config.h
+++ firefox-50.0.2/media/webrtc/trunk/build/build_config.h
@@ -129,7 +129,7 @@
 #define ARCH_CPU_PPC 1
 #define ARCH_CPU_32_BITS 1
 #define ARCH_CPU_BIG_ENDIAN 1
-#elif defined(__sparc64__)
+#elif defined(__sparc__) && defined(__arch64__)
 #define ARCH_CPU_SPARC_FAMILY 1
 #define ARCH_CPU_SPARC 1
 #define ARCH_CPU_64_BITS 1
Index: firefox-50.0.2/media/webrtc/trunk/webrtc/typedefs.h
===
---

Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions

2016-12-12 Thread John Paul Adrian Glaubitz 
On 12/12/2016 12:38 AM, John Paul Adrian Glaubitz wrote:
> On 12/12/2016 12:20 AM, John Paul Adrian Glaubitz wrote:
>> Attaching my latest patch which makes use of the ARM64 memory allocator, 
>> both for the
>> Javascript engine as well as mozjemalloc. It seems to fix the memory 
>> corruption and
>> allocation issues, but Firefox now crashes with SIGBUS in the xulrunner stub 
>> (see
>> below).
> 
> Looks like I forgot this:

YES, that did the trick (in a slightly changed version):

Build Architecture: sparc64
Build-Space: 9509324
Build-Time: 2447
Distribution: sid
Host Architecture: sparc64
Install-Time: 22
Job: /home/glaubitz/firefox_50.0.2-1.dsc
Machine Architecture: sparc64
Package: firefox
Package-Time: 2635
Source-Version: 50.0.2-1
Space: 9509324
Status: successful
Version: 50.0.2-1

Now to clean up my patch :D.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions

2016-12-11 Thread John Paul Adrian Glaubitz 
On 12/12/2016 12:20 AM, John Paul Adrian Glaubitz wrote:
> Attaching my latest patch which makes use of the ARM64 memory allocator, both 
> for the
> Javascript engine as well as mozjemalloc. It seems to fix the memory 
> corruption and
> allocation issues, but Firefox now crashes with SIGBUS in the xulrunner stub 
> (see
> below).

Looks like I forgot this:

Index: firefox-50.0.2/xpcom/reflect/xptcall/md/unix/moz.build
===
--- firefox-50.0.2.orig/xpcom/reflect/xptcall/md/unix/moz.build
+++ firefox-50.0.2/xpcom/reflect/xptcall/md/unix/moz.build
@@ -264,6 +256,14 @@ if CONFIG['OS_ARCH'] in ('OpenBSD', 'Fre
 'xptcstubs_sparc64_openbsd.cpp',
 ]

+if CONFIG['OS_ARCH'] in ('Linux') and CONFIG['OS_TEST'] == 'sparc64':
+SOURCES += [
+'xptcinvoke_asm_sparc64_linux.s',
+'xptcinvoke_sparc64_linux.cpp',
+'xptcstubs_asm_sparc64_linux.s',
+'xptcstubs_sparc64_linux.cpp',
+]
+
 if CONFIG['OS_ARCH'] == 'SunOS' and '86' not in CONFIG['OS_TEST']:
 if CONFIG['HAVE_64BIT_BUILD']:
 ASFLAGS += ['-xarch=v9']

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions

2016-12-11 Thread John Paul Adrian Glaubitz 
Attaching my latest patch which makes use of the ARM64 memory allocator, both 
for the
Javascript engine as well as mozjemalloc. It seems to fix the memory corruption 
and
allocation issues, but Firefox now crashes with SIGBUS in the xulrunner stub 
(see
below).

If anyone wants to have a go at this, just get the source of the current firefox
package in Debian (version 50) and apply the patch with "patch -p1", then run
"dpkg-source --commit" in the source tree to apply the patch to quilt.

Thanks,
Adrian

Thread 1 "xpcshell" received signal SIGBUS, Bus error.
0xfff8000100c12224 in invoke_copy_to_stack (d=, 
paramCount=, s=)
at 
/build/firefox-wic4ZJ/firefox-50.0.2/xpcom/reflect/xptcall/md/unix/xptcinvoke_sparc_solaris.cpp:126
126 break;
(gdb)  bt
#0  0xfff8000100c12224 in invoke_copy_to_stack (d=, 
paramCount=, s=)
at 
/build/firefox-wic4ZJ/firefox-50.0.2/xpcom/reflect/xptcall/md/unix/xptcinvoke_sparc_solaris.cpp:126
#1  0xfff8000100c1760c in NS_InvokeByIndex ()
at 
/build/firefox-wic4ZJ/firefox-50.0.2/xpcom/reflect/xptcall/md/unix/xptcinvoke_asm_sparc_linux_GCC3.s:32
#2  0xfff800010116084c in CallMethodHelper::Invoke (this=0x7fec6a8)
at 
/build/firefox-wic4ZJ/firefox-50.0.2/js/xpconnect/src/XPCWrappedNative.cpp:2075
#3  CallMethodHelper::Call (this=0x7fec6a8)
at 
/build/firefox-wic4ZJ/firefox-50.0.2/js/xpconnect/src/XPCWrappedNative.cpp:1394
#4  XPCWrappedNative::CallMethod (ccx=..., 
mode=mode@entry=XPCWrappedNative::CALL_GETTER)
at 
/build/firefox-wic4ZJ/firefox-50.0.2/js/xpconnect/src/XPCWrappedNative.cpp:1361
#5  0xfff8000101167560 in XPCWrappedNative::GetAttribute (ccx=...)
at /build/firefox-wic4ZJ/firefox-50.0.2/js/xpconnect/src/xpcprivate.h:1950
#6  XPC_WN_GetterSetter (cx=, cx@entry=0x7000189a000, 
argc=, vp=0x7fecc28)
at 
/build/firefox-wic4ZJ/firefox-50.0.2/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1164
#7  0xfff8000102bacc5c in js::CallJSNative (args=..., native=, 
cx=0x7000189a000)
at /build/firefox-wic4ZJ/firefox-50.0.2/js/src/jscntxtinlines.h:235
#8  js::InternalCallOrConstruct (cx=0x7000189a000, args=..., 
construct=)
at /build/firefox-wic4ZJ/firefox-50.0.2/js/src/vm/Interpreter.cpp:453
#9  0xfff8000102bacde0 in InternalCall (cx=cx@entry=0x7000189a000, args=...)
at /build/firefox-wic4ZJ/firefox-50.0.2/js/src/vm/Interpreter.cpp:498
#10 0xfff8000102bace50 in js::Call (cx=cx@entry=0x7000189a000, fval=..., 
thisv=..., args=..., rval=...)
at /build/firefox-wic4ZJ/firefox-50.0.2/js/src/vm/Interpreter.cpp:517
#11 0xfff8000102bacf08 in js::CallGetter (cx=cx@entry=0x7000189a000, thisv=..., 
getter=..., rval=...)
at /build/firefox-wic4ZJ/firefox-50.0.2/js/src/vm/Interpreter.cpp:631
#12 0xfff8000102bacfe0 in CallGetter (cx=cx@entry=0x7000189a000, obj=..., 
receiver=..., shape=..., vp=...)
at /build/firefox-wic4ZJ/firefox-50.0.2/js/src/vm/NativeObject.cpp:1737
#13 0xfff8000102bad264 in GetExistingProperty<(js::AllowGC)1> (vp=..., 
shape=..., obj=..., receiver=..., cx=0x7000189a000)
at /build/firefox-wic4ZJ/firefox-50.0.2/js/src/vm/NativeObject.cpp:1785
#14 NativeGetPropertyInline<(js::AllowGC)1> (vp=..., nameLookup=NotNameLookup, 
id=..., receiver=..., obj=...,
---Type  to continue, or q  to quit---
0) at /build/firefox-wic4ZJ/firefox-50.0.2/js/src/vm/NativeObject.cpp:2012

#15 js::NativeGetProperty (cx=0x7000189a000, obj=..., receiver=..., id=..., 
vp=...) at /build/firefox-wic4ZJ/firefox-50.0.2/js/src/vm/NativeObject.cpp:2046

#16 0xfff8000102a264b0 in js::GetProperty (cx=cx@entry=0x7000189a000, obj=..., 
receiver=..., id=..., vp=...) at
/build/firefox-wic4ZJ/firefox-50.0.2/js/src/vm/NativeObject.h:1478
#17 0xfff8000102bae7f0 in js::GetProperty (vp=..., name=, 
receiver=..., obj=..., cx=0x7000189a000) at
/build/firefox-wic4ZJ/firefox-50.0.2/js/src/jsobj.h:836
#18 js::GetProperty (cx=0x7000189a000, v=..., name=..., vp=...) at 
/build/firefox-wic4ZJ/firefox-50.0.2/js/src/vm/Interpreter.cpp:4161

#19 0xfff8000102ba1bb4 in GetPropertyOperation (vp=..., lval=..., pc=, script=..., fp=, cx=)

at /build/firefox-wic4ZJ/firefox-50.0.2/js/src/vm/Interpreter.cpp:189

#20 Interpret (cx=0x7000189a000, state=...) at 
/build/firefox-wic4ZJ/firefox-50.0.2/js/src/vm/Interpreter.cpp:2590

#21 0xfff8000102bac9a4 in js::RunScript (cx=cx@entry=0x7000189a000, state=...) 
at /build/firefox-wic4ZJ/firefox-50.0.2/js/src/vm/Interpreter.cpp:399

#22 0xfff8000102bb55a4 in js::ExecuteKernel (cx=cx@entry=0x7000189a000, 
script=..., scopeChainArg=..., newTargetValue=..., evalInFrame=...,
result=result@entry=0x7fed990)
at /build/firefox-wic4ZJ/firefox-50.0.2/js/src/vm/Interpreter.cpp:679

#23 0xfff8000102bb56ec in js::Execute (cx=cx@entry=0x7000189a000, script=..., 
scopeChainArg=..., rval=rval@entry=0x7fed990)

at /build/firefox-wic4ZJ/firefox-50.0.2/js/src/vm/Interpreter.cpp:712

#24 0xfff8000102a25a9c in ExecuteScript (cx=cx@entry=0x7000189a000, scope=..., 
script=..., rval=rval@entry=0x7fed990) at

Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions

2016-05-22 Thread John Paul Adrian Glaubitz 
On 05/22/2016 11:49 AM, John Paul Adrian Glaubitz wrote:
> I have been playing a bit more and tried a dirty hack to convince mmap to not
> ignore the hint, I just substracted random(), e.g.:
> 
> ret = mmap(addr-random(), size, PROT_READ | PROT_WRITE, MAP_PRIVATE | 
> MAP_ANON, -1, 0);
> 
> in memory/mozjemalloc/jemalloc.c in pages_map().

And, of course, for the mmap() calls in js/src/gc/Memory.cpp and 
js/src/jsapi-tests/
testGCAllocator.cpp, e.g. the calls for which NetBSD/sparc64 is tuned to use a 
hint
for mmap() [1].

Adrian

> [1] https://hg.mozilla.org/mozilla-central/rev/9ea1e520692e

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions

2016-05-22 Thread John Paul Adrian Glaubitz 
I have been playing a bit more and tried a dirty hack to convince mmap to not
ignore the hint, I just substracted random(), e.g.:

ret = mmap(addr-random(), size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, 
-1, 0);

in memory/mozjemalloc/jemalloc.c in pages_map().

This actually fixes the crash in xpcshell for me, although it's not reliable
on more complex code:

(sid)root@deb4g:/build/firefox-ORgwZM/firefox-46.0.1# 
./build-browser/dist/bin/xpcshell

(process:201760): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
js> print("Hello World!");
Hello World!
js>

(sid)root@deb4g:/build/firefox-ORgwZM/firefox-46.0.1/build-browser# 
/build/firefox-ORgwZM/firefox-46.0.1/build-browser/dist/bin/xpcshell -g
/build/firefox-ORgwZM/firefox-46.0.1/build-browser/dist/bin/ -a 
/build/firefox-ORgwZM/firefox-46.0.1/build-browser/dist/bin/ -f
/build/firefox-ORgwZM/firefox-46.0.1/toolkit/mozapps/installer/precompile_cache.js
 -e precompile_startupcache\("resource://gre/"\);

(process:201945): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
Segmentation fault
(sid)root@deb4g:/build/firefox-ORgwZM/firefox-46.0.1/build-browser#

So, while we have now verified this is actually a problem with the memory region
being used, i.e. the same problem as on NetBSD, we don't have a proper fix for
it yet, unfortunately.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions

2016-05-20 Thread John Paul Adrian Glaubitz 
On Fri, May 20, 2016 at 11:06:06PM +0200, John Paul Adrian Glaubitz wrote:
> Thus, in order to fix this issue on sparc64/Linux, a more elaborate
> fix will have to be developed.

I just made a test installation of NetBSD to verify the theory.

On Linux:

glaubitz@ikarus:~$ cat vmtest.c 
#include 
#include 

int main(void)
{
void *ptr1, *ptr2, *ptr3, *ptr4, *ptr5, *ptr6;
ptr1 = mmap(NULL, 1024*1024, PROT_READ | PROT_WRITE, MAP_PRIVATE | 
MAP_ANONYMOUS, -1, 0);
ptr2 = mmap((void*)0x0700ULL, 1024*1024, PROT_READ | 
PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
ptr3 = mmap((void*)0x0700ULL, 1024*1024, PROT_READ | 
PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
ptr4 = mmap((void*)0x0700ULL, 1024*1024, PROT_READ | 
PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
ptr5 = mmap((void*)0x0700ULL, 1024*1024, PROT_READ | 
PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
ptr6 = mmap(NULL, 1024*1024, PROT_READ | PROT_WRITE, MAP_PRIVATE | 
MAP_ANONYMOUS, -1, 0);
printf("%p %p %p %p %p %p\n", ptr1, ptr2, ptr3, ptr4, ptr5, ptr6);
}
glaubitz@ikarus:~$ ./vmtest 
0x7f80c32f6000 0x700 0x7f80c2d5d000 0x7f80c2c5d000 0x7f80c2b5d000 
0x7f80c2a5d000
glaubitz@ikarus:~$ uname -vm
#1 SMP Debian 4.5.1-1 (2016-04-14) x86_64
glaubitz@ikarus:~$

On NetBSD:

testbsd# cat vmtest.c
#include 
#include 

int main(void)
{
void *ptr1, *ptr2, *ptr3, *ptr4, *ptr5, *ptr6;
ptr1 = mmap(NULL, 1024*1024, PROT_READ | PROT_WRITE, MAP_PRIVATE | 
MAP_ANONYMOUS, -1, 0);
ptr2 = mmap((void*)0x0700ULL, 1024*1024, PROT_READ | 
PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
ptr3 = mmap((void*)0x0700ULL, 1024*1024, PROT_READ | 
PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
ptr4 = mmap((void*)0x0700ULL, 1024*1024, PROT_READ | 
PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
ptr5 = mmap((void*)0x0700ULL, 1024*1024, PROT_READ | 
PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
ptr6 = mmap(NULL, 1024*1024, PROT_READ | PROT_WRITE, MAP_PRIVATE | 
MAP_ANONYMOUS, -1, 0);
printf("%p %p %p %p %p %p\n", ptr1, ptr2, ptr3, ptr4, ptr5, ptr6);
}
testbsd# ./vmtest
0x7f7ff7ef8000 0x700 0x6f0 0x6e0 0x6d0 
0x7f7ff7b0
testbsd# uname -vm
NetBSD 7.0 (GENERIC.201509250726Z) amd64
testbsd#

As you can see, on NetBSD, mmmap with a hint will always return memory
in the requested region, even if the memory has already been allocated
before. On Linux, the hint is ignored when the memory pointed to by it
is already allocated.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions

2016-05-20 Thread John Paul Adrian Glaubitz 
Hi!

Some more updates:

Jose Marchesi from Oracle has provided me with two old patches that
were used to address the problem with Firefox 17.

Those patches are:

- xulrunner-linux-sparc64-xpcom.patch
- xulrunner-linux-sparc64.patch

Those patches didn't apply anymore right away. I had to update some
paths (src was omitted in some cases), plus the two following
changes:

1. I adjusted the padding in JSTryNote so it would be 64-bit aligned
   again as Firefox 46 changed stackDepth from uint16_t to uint32_t.

2. The patch to memory/jemalloc/src/include/jemalloc/internal
   /jemalloc_internal.h.in can't be applied anymore at all, even
   with editing. The code section is gone.

With these changes included, the new patch (sparc64-fixes.patch)
applies without problems but compiling Firefox will still crash
xpcshell:

(sid)root@deb4g:/build/firefox-ORgwZM/firefox-46.0.1# export
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/build/firefox-ORgwZM/firefox-46.0.1/build-browser/dist/bin/
(sid)root@deb4g:/build/firefox-ORgwZM/firefox-46.0.1#
./build-browser/dist/bin/xpcshell

(process:240502): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
Segmentation fault
(sid)root@deb4g:/build/firefox-ORgwZM/firefox-46.0.1#

The backtrace looks like this:

(gdb) bt
#0  0xfff8000102a117c4 in js::gc::Cell::storeBuffer (this=) at /build/firefox-F4xXKx/firefox-46.0.1/js/src/gc/Heap.h:1339
#1  js::HeapSlot::post (target=..., slot=0, kind=js::HeapSlot::Slot,
owner=0xfff8000112523070, this=0xfff8000112523090)
at /build/firefox-F4xXKx/firefox-46.0.1/js/src/gc/Barrier.h:692
#2  js::HeapSlot::set (this=0xfff8000112523090,
owner=owner@entry=0xfff8000112523070, slot=slot@entry=0, v=...,
kind=js::HeapSlot::Slot)
at /build/firefox-F4xXKx/firefox-46.0.1/js/src/gc/Barrier.h:679
#3  0xfff8000102a13634 in js::NativeObject::setSlot
(this=0xfff8000112523070, value=..., slot=0)
at /build/firefox-F4xXKx/firefox-46.0.1/js/src/vm/NativeObject.h:824
#4  0xfff8000102a13758 in js::NativeObject::setReservedSlot (v=...,
index=0, this=)
at /build/firefox-F4xXKx/firefox-46.0.1/js/src/vm/NativeObject.h:890
#5  js::ClonedBlockObject::create (cx=cx@entry=0xfff800010a73a400,
block=..., enclosing=...)
at /build/firefox-F4xXKx/firefox-46.0.1/js/src/vm/ScopeObject.cpp:945
#6  0xfff8000102a18f1c in js::ClonedBlockObject::createGlobal
(cx=cx@entry=0xfff800010a73a400, global=...)
at /build/firefox-F4xXKx/firefox-46.0.1/js/src/vm/ScopeObject.cpp:976
#7  0xfff80001029b43fc in js::GlobalObject::createInternal
(cx=cx@entry=0xfff800010a73a400,
clasp=0xfff8000103e07028
) at
/build/firefox-F4xXKx/firefox-46.0.1/js/src/vm/GlobalObject.cpp:278
#8  0xfff8000102a062bc in JSRuntime::createSelfHostingGlobal
(cx=cx@entry=0xfff800010a73a400)
at /build/firefox-F4xXKx/firefox-46.0.1/js/src/vm/SelfHosting.cpp:1956
#9  0xfff8000102a08988 in JSRuntime::initSelfHosting
(this=this@entry=0xfff800010c3d2000, cx=cx@entry=0xfff800010a73a400)
at /build/firefox-F4xXKx/firefox-46.0.1/js/src/vm/SelfHosting.cpp:1988
#10 0xfff8000102876f74 in js::NewContext (rt=0xfff800010c3d2000,
rt@entry=0x0, stackChunkSize=stackChunkSize@entry=8192)
at /build/firefox-F4xXKx/firefox-46.0.1/js/src/jscntxt.cpp:121
#11 0xfff8000102876fbc in JS_NewContext (rt=0x0,
stackChunkSize=stackChunkSize@entry=8192) at
/build/firefox-F4xXKx/firefox-46.0.1/js/src/jsapi.cpp:573
#12 0xfff8000101058308 in XPCJSContextStack::InitSafeJSContext
(this=0xfff800010b248240)
at
/build/firefox-F4xXKx/firefox-46.0.1/js/xpconnect/src/XPCJSContextStack.cpp:122
#13 0xfff80001010738ac in nsXPConnect::InitStatics () at
/build/firefox-F4xXKx/firefox-46.0.1/js/xpconnect/src/nsXPConnect.cpp:126
#14 0xfff800010105ccd4 in xpcModuleCtor () at
/build/firefox-F4xXKx/firefox-46.0.1/js/xpconnect/src/XPCModule.cpp:13
#15 0xfff800010229b818 in Initialize () at
/build/firefox-F4xXKx/firefox-46.0.1/layout/build/nsLayoutModule.cpp:436
#16 0xfff8000100bf9070 in nsComponentManagerImpl::KnownModule::Load
(this=0xfff800010b22f280)
at
/build/firefox-F4xXKx/firefox-46.0.1/xpcom/components/nsComponentManager.cpp:898
#17 0xfff8000100bfa018 in nsFactoryEntry::GetFactory
(this=0xfff800010b23a180)
at
/build/firefox-F4xXKx/firefox-46.0.1/xpcom/components/nsComponentManager.cpp:1934
#18 0xfff8000100bfa8d4 in
nsComponentManagerImpl::CreateInstanceByContractID
(this=0xfff800010a7f60c0,
aContractID=0xfff8000102bb8b98 "@mozilla.org/moz/jsloader;1",
aDelegate=0x0, aIID=..., aResult=0x7fee930)
at
/build/firefox-F4xXKx/firefox-46.0.1/xpcom/components/nsComponentManager.cpp:1232
#19 0xfff8000100bfc298 in nsComponentManagerImpl::GetServiceByContractID
(this=0xfff800010a7f60c0,
aContractID=0xfff8000102bb8b98 "@mozilla.org/moz/jsloader;1",
aIID=..., aResult=0x7feeac0)
at
/build/firefox-F4xXKx/firefox-46.0.1/xpcom/components/nsComponentManager.cpp:1592
#20 0xfff8000100c28514 in CallGetService (aContractID=0xfff8000102bab760

Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions

2016-05-20 Thread John Paul Adrian Glaubitz 
On 05/16/2016 10:15 AM, John Paul Adrian Glaubitz wrote:
> After applying both patches, the build *almost* finishes on sparc64,
> in fact, it fails at dh_auto_install with [2]:
> 
> Executing /<>/build-browser/dist/bin/xpcshell -g 
> /<>/build-browser/dist/bin/ -a 
> /<>/build-browser/dist/bin/ -f 
> /<>/toolkit/mozapps/installer/precompile_cache.js -e 
> precompile_startupcache("resource://gre/");
> Traceback (most recent call last):
>   File "/<>/toolkit/mozapps/installer/packager.py", line 410, in 
> 
> main()
>   File "/<>/toolkit/mozapps/installer/packager.py", line 404, in 
> main
> args.source, gre_path, base)
>   File "/<>/toolkit/mozapps/installer/packager.py", line 161, in 
> precompile_cache
> errors.fatal('Error while running startup cache precompilation')
>   File "/<>/python/mozbuild/mozpack/errors.py", line 103, in 
> fatal
> self._handle(self.FATAL, msg)
>   File "/<>/python/mozbuild/mozpack/errors.py", line 98, in 
> _handle
> raise ErrorMessage(msg)
> mozpack.errors.ErrorMessage: Error: Error while running startup cache 
> precompilation

Seems that there is a relevant upstream bug report for that:

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

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions

2016-05-16 Thread John Paul Adrian Glaubitz 
Source: firefox
Version: 46.0.1-1
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hi!

I have had a look at the firefox package on sparc64 and I was able to detect
two problems with platform definitions which prevent an almost successful
build on this architecture.

Firstly, the embedded version of protobuf contains the same bug that we
have already fixed in the protobuf package in Debian which is basically
a missing #ifdef for 'sparc64' [1]:

--- 
firefox-46.0.1.orig/toolkit/components/protobuf/src/google/protobuf/stubs/platform_macros.h
+++ 
firefox-46.0.1/toolkit/components/protobuf/src/google/protobuf/stubs/platform_macros.h
@@ -67,7 +67,7 @@
 #define GOOGLE_PROTOBUF_ARCH_32_BIT 1
 #elif defined(sparc)
 #define GOOGLE_PROTOBUF_ARCH_SPARC 1
-#ifdef SOLARIS_64BIT_ENABLED
+#if defined(SOLARIS_64BIT_ENABLED) || defined(__LP64__)
 #define GOOGLE_PROTOBUF_ARCH_64_BIT 1
 #else
 #define GOOGLE_PROTOBUF_ARCH_32_BIT 1

Note: This cannot be fixed by checking for '__sparc64__' as the compiler
does not generate this definition on sparc64:

root@landau:~# dpkg --print-architecture
sparc64
root@landau:~# echo | gcc -E -dM - |grep sparc64
root@landau:~#

Instead, we need to check for both __sparc__ and __arch64__:

root@landau:~# echo | gcc -E -dM - |grep __sparc__
#define __sparc__ 1
root@landau:~# echo | gcc -E -dM - |grep __arch64__
#define __arch64__ 1
root@landau:~#

Which will bring us also directly to the second problem which prevents
building of firefox on sparc64. It's actually the incorrect checking
for __sparc64__ in ipc/chromium which can be trivially fixed with:

--- firefox-46.0.1.orig/ipc/chromium/src/build/build_config.h
+++ firefox-46.0.1/ipc/chromium/src/build/build_config.h
@@ -81,7 +81,7 @@
 #elif defined(__ppc__) || defined(__powerpc__)
 #define ARCH_CPU_PPC 1
 #define ARCH_CPU_32_BITS 1
-#elif defined(__sparc64__)
+#elif defined(__sparc__) && defined(__arch64__)
 #define ARCH_CPU_SPARC 1
 #define ARCH_CPU_64_BITS 1
 #elif defined(__sparc__)

After applying both patches, the build *almost* finishes on sparc64,
in fact, it fails at dh_auto_install with [2]:

Executing /<>/build-browser/dist/bin/xpcshell -g 
/<>/build-browser/dist/bin/ -a 
/<>/build-browser/dist/bin/ -f 
/<>/toolkit/mozapps/installer/precompile_cache.js -e 
precompile_startupcache("resource://gre/");
Traceback (most recent call last):
  File "/<>/toolkit/mozapps/installer/packager.py", line 410, in 

main()
  File "/<>/toolkit/mozapps/installer/packager.py", line 404, in 
main
args.source, gre_path, base)
  File "/<>/toolkit/mozapps/installer/packager.py", line 161, in 
precompile_cache
errors.fatal('Error while running startup cache precompilation')
  File "/<>/python/mozbuild/mozpack/errors.py", line 103, in fatal
self._handle(self.FATAL, msg)
  File "/<>/python/mozbuild/mozpack/errors.py", line 98, in _handle
raise ErrorMessage(msg)
mozpack.errors.ErrorMessage: Error: Error while running startup cache 
precompilation

which seems to be the exact same problem which also prevents the build on hppa 
[3].

It would be great if the two above changes could be merged into the firefox 
package
in Debian plus someone should also forward this bug report upstream. Then we 
just
need to figure out what's wrong with the startup cache precompiliation and might
be able to fix firefox on both hppa and sparc64.

Cheers,
Adrian

> [1] 
> https://anonscm.debian.org/cgit/pkg-protobuf/pkg-protobuf.git/tree/debian/patches/02-fix-sparc64-builds.patch
> [2] 
> https://buildd.debian.org/status/fetch.php?pkg=firefox=sparc64=46.0.1-1=1463370916
> [3] 
> https://buildd.debian.org/status/fetch.php?pkg=firefox=hppa=46.0.1-1=1462743802

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913