Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 462608

Summary: www-client/firefox-{19..24}.0 fail to build with clang and clang+lto
Product: Gentoo Linux Reporter: cmuelle8 <cmue81>
Component: Current packagesAssignee: Mozilla Gentoo Team <mozilla>
Status: RESOLVED OBSOLETE    
Severity: normal CC: cmosqt, pageexec
Priority: Normal Keywords: PATCH
Version: unspecified   
Hardware: All   
OS: Linux   
See Also: https://bugzilla.mozilla.org/show_bug.cgi?id=928808
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on: 462488, 462554    
Bug Blocks: 408963, 618550    
Attachments: patches (elfhack, debug flags, mssse3 detection issue)
paludis/cave build log of firefox build using gcc-4.7.2 -O2 -flto
firefox-19.0.2-clang-and-config.guess.patch
firefox-19.0.2.ebuild.patch
firefox-19.0.2.ebuild.patch
firefox-19.0.2.ebuild.patch
/etc/portage/patches/www-client/firefox-19.0.2/firefox-19.0.2-clang-3.3svn.patch
/etc/portage/patches/www-client/firefox-21.0/firefox-21.0-clang-3.3svn.patch
firefox-20.0.1.ebuild.patch
firefox-21.0.ebuild.patch
firefox-21.0.ebuild.patch
/etc/portage/patches/www-client/firefox-21.0/firefox-21.0-clang-3.4svn.patch
/etc/portage/patches/www-client/firefox/firefox-24.0-clang-3.x.patch
firefox-22.0.ebuild.patch
build log showing clang linking error, if ssse3 detection is not moved in configure.in
firefox-22.0.ebuild.patch
firefox-24.0-r1.ebuild.patch
/etc/portage/patches/www-client/firefox/firefox-24.0-clang-3.x.patch
/etc/portage/patches/www-client/firefox/928808_no_inline.patch

Description cmuelle8 2013-03-21 17:47:19 UTC
Using the steps described below I was able to produce a running build, though it segfaults using "-O4" when run.  This might be caused by the experimental nature of -9999 builds of clang/llvm.  Have fun experimenting yourself.


firefox-19.0.2 / clang-9999+lto / llvm-9999 build issues


- currently live ebuilds from trunk are versioned llvm-3.3svn, keyword -9999 versions and build them

- make ar, nm tools of binutils use llvm linker plugins
see bug #462554

- patch mozcoreconf-2.eclass to allow passing O4 as an optimization flag
see bug #462488

- enable clang/llvm environment for FF in /etc/paludis/bashrc
case "${CATEGORY}/${PN}" in
        www-client/firefox) ;&
        "USE-CLANG-AND-LLVM")
                CC="clang"
                CXX="clang++"
                CFLAGS="${CFLAGS%% -O*} -O4"
                LDFLAGS="${LDFLAGS}"
                #LDFLAGS="${LDFLAGS} -Wl,-z,norelro"
                #CFLAGS="${CFLAGS} -v"
                ;;
esac


- enable FF use flags in /etc/paludis/use.conf
www-client/firefox custom-cflags
www-client/firefox custom-optimization


- patch FF source, place user patch in /etc/portage/patches/www-client/firefox/
configure.in (js and topdir) to not use "-g" MOZ_DEBUG_FLAGS
configure.in to not use -mssse3 test (always positive using clang)
  moved -mssse3 test to "if -z $INTEL_CC -a -z $CLANG_CC .." section
  for amdfam10 / amd phenom cpu, look at ssse3 bugs posted here:
    http://llvm.org/bugs/show_bug.cgi?id=13000
    https://bugzilla.mozilla.org/show_bug.cgi?id=759683
Makefile.in elfhack special treatment for -O* to let tests (array+ctors) pass
  alternatively you may try --disable-elf-hack, but you cannot pass this via EXTRA_ECONF
  patch mozcoreconf-2.eclass and use mozconfig_annotate if you want to do this
  elfhack related links/bugs:
    http://blog.mozilla.org/respindola/2011/02/23/lto-with-elfhack/
    http://code.metager.de/source/history/mozilla/tracemonkey/build/unix/elfhack/Makefile.in
    http://hg.mozilla.org/mozilla-central/rev/494662b968c2
    https://bugzilla.mozilla.org/show_bug.cgi?id=635966
    https://bugzilla.mozilla.org/show_bug.cgi?id=664366



- example build info for an amd64 host, phenom ii cpu

linking time and mem resources for libxul.so
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
31005 paludis+  20   0 3983220 3,736g 272932 R 93,82 23,87  35:28.39 x86_64-pc-linux

binary sizes (1k blocks, elf-hack enabled see patch above)
40304 /usr/lib64/firefox/libxul.so
 8476 /usr/lib64/firefox/omni.ja
  316 /usr/lib64
  232 /usr/bin
   88 /usr/lib64/firefox/webapprt-stub
   84 /usr/lib64/firefox/mozilla-xremote-client
   80 /usr/lib64/firefox/firefox
   80 /usr/lib64/firefox/firefox-bin

binary sizes (1k blocks, --disable-elf-hack passed to mozconfig)
46132 /usr/lib64/firefox/libxul.so
 8480 /usr/lib64/firefox/omni.ja
  316 /usr/lib64
  232 /usr/bin
   88 /usr/lib64/firefox/webapprt-stub
   84 /usr/lib64/firefox/mozilla-xremote-client
   80 /usr/lib64/firefox/firefox
   80 /usr/lib64/firefox/firefox-bin



Reproducible: Always
Comment 1 cmuelle8 2013-03-21 17:48:32 UTC
Created attachment 342858 [details, diff]
patches (elfhack, debug flags, mssse3 detection issue)

you might not need to patch out mssse3 detection if you're on a host that supports it
Comment 2 cmuelle8 2013-03-22 08:22:14 UTC
- this is for an "-O2 -flto" build with clang, elfhack enabled

39528 /usr/lib64/firefox/libxul.so
 8476 /usr/lib64/firefox/omni.ja
  316 /usr/lib64
  232 /usr/bin
   84 /usr/lib64/firefox/webapprt-stub
   80 /usr/lib64/firefox/mozilla-xremote-client
   76 /usr/lib64/firefox/firefox
   76 /usr/lib64/firefox/firefox-bin

-> segfaults in libxul.so while running as well (dromaeo.com to test)


- reference size for a usual "-O2" build with gcc, elfhack enabled

36560 /usr/lib64/firefox/libxul.so
 8476 /usr/lib64/firefox/omni.ja
  316 /usr/lib64
  232 /usr/bin
  128 /usr/lib64/firefox/webapprt-stub
  104 /usr/lib64/firefox/firefox
  104 /usr/lib64/firefox/firefox-bin

-> works fine
Comment 3 cmuelle8 2013-03-22 17:02:28 UTC
- this is for an "-O2" build with clang-9999, elfhack enabled, lto disabled

34548 /usr/lib64/firefox/libxul.so
 8476 /usr/lib64/firefox/omni.ja
  316 /usr/lib64
  232 /usr/bin
  120 /usr/lib64/firefox/webapprt-stub
   96 /usr/lib64/firefox/firefox
   96 /usr/lib64/firefox/firefox-bin

-> segfaults in libxul.so while dromaeo.com loads (like all other builds with clang so far)


- for completeness, these were the base flags used in /etc/paludis/bashrc for all compiles, with varying O*/-flto variations to CFLAGS as noted for the individual cases above, and the addition of -Wl,-z,norelro to LDFLAGS when clang was used

CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=native -pipe -O2"
LDFLAGS="-Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common"
MAKEOPTS="-j1"


So far the only stable firefox-compile in my short test series was the "usual" one with gcc (-O2, elfhack enabled, lto disabled).  The comparison is biased, since gcc-4.7.2 is a stable release and the clang/llvm I used were live versions from svn trunk.  The tests done so far, in chronological order, first field shows libxul size:

[40.304] [unstable] clang-9999 -O4
[46.132] [unstable] clang-9999 -O4  (--disable-elf-hack)
[39.528] [unstable] clang-9999 -O2 -flto
[36.560] [  stable] gcc-4.7.2  -O2
[34.548] [unstable] clang-9999 -O2


Greetings
Comment 4 cmuelle8 2013-03-22 17:31:06 UTC
Created attachment 342926 [details]
paludis/cave build log of firefox build using gcc-4.7.2 -O2 -flto

The test series omits results for an gcc "-O2 -flto" build.  Trying this, compilation interrupted with an error linking jsheaptools, see attachment for full build log.  Excerpt:

x86_64-pc-linux-gnu-g++ -o jsheaptools.o -c  -I../../../dist/system_wrappers_js -include /var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/js/src/config/gcc_hidden.h -DEXPORT_JS_API -DIMPL_MFBT -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_SUPPORT -I/var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/js/src -I.. -I/var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/js/src/shell -I. -I../../../dist/include  -I/usr/include/nspr       -fPIC  -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Werror=conversion-null -Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align -march=native -pipe -mfpmath=sse -flto=4 -floop-block -floop-interchange -floop-strip-mine -fuse-linker-plugin -mno-avx -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -pthread -pipe  -DNDEBUG -DTRIMMED  -O2 -fomit-frame-pointer   -DMOZILLA_CLIENT -include ../js-confdefs.h -MD -MF .deps/jsheaptools.o.pp  /var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/js/src/shell/jsheaptools.cpp
/usr/bin/python2.7 /var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/js/src/config/pythonpath.py -I../config /var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/js/src/config/expandlibs_exec.py --depend .deps/js.pp --target js --uselist --  x86_64-pc-linux-gnu-g++ -o js  -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Werror=conversion-null -Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align -march=native -pipe -mfpmath=sse -flto=4 -floop-block -floop-interchange -floop-strip-mine -fuse-linker-plugin -mno-avx -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -pthread -pipe  -DNDEBUG -DTRIMMED  -O2 -fomit-frame-pointer js.o jsoptparse.o jsheaptools.o   -lpthread -march=native -pipe -mfpmath=sse -flto=4 -floop-block -floop-interchange -floop-strip-mine -fuse-linker-plugin -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -Wl,--icf=safe   -Wl,-rpath-link,../../../dist/bin -Wl,-rpath-link,/var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/obj-x86_64-unknown-linux-gnu/dist/lib   -L../../../dist/bin -L../../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl ../editline/libeditline.a ../libjs_static.a -lz -Wl,--whole-archive ../../../dist/lib/libmozglue.a ../../../dist/lib/libmemory.a -Wl,--no-whole-archive -rdynamic -ldl  -lffi   
/var/tmp/paludis/www-client-firefox-19.0.2/temp//ccg5er9g.ltrans0.ltrans.o(.text+0x36): error: undefined reference to 'PushActiveVMFrame'
/var/tmp/paludis/www-client-firefox-19.0.2/temp//ccg5er9g.ltrans0.ltrans.o(.text+0x49): error: undefined reference to 'PopActiveVMFrame'
/var/tmp/paludis/www-client-firefox-19.0.2/temp//ccg5er9g.ltrans0.ltrans.o(.text+0x68): error: undefined reference to 'js_InternalThrow'
/var/tmp/paludis/www-client-firefox-19.0.2/temp//ccg5er9g.ltrans0.ltrans.o(.text+0x77): error: undefined reference to 'PopActiveVMFrame'
/var/tmp/paludis/www-client-firefox-19.0.2/temp//ccg5er9g.ltrans0.ltrans.o(.text+0x95): error: undefined reference to 'js_InternalInterpret'
/var/tmp/paludis/www-client-firefox-19.0.2/temp//ccg5er9g.ltrans0.ltrans.o(.text+0xbc): error: undefined reference to 'PopActiveVMFrame'
collect2: error: ld returned 1 exit status
make[6]: *** [js] Error 1make[6]: Leaving directory `/var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/obj-x86_64-unknown-linux-gnu/js/src/shell'
Comment 5 cmuelle8 2013-03-23 13:16:25 UTC
(In reply to comment #3)
> - this is for an "-O2" build with clang-9999, elfhack enabled, lto disabled
> 
> 34548 /usr/lib64/firefox/libxul.so
> [...]
> [40.304] [unstable] clang-9999 -O4
> [46.132] [unstable] clang-9999 -O4  (--disable-elf-hack)
> [39.528] [unstable] clang-9999 -O2 -flto
> [36.560] [  stable] gcc-4.7.2  -O2
> [34.548] [unstable] clang-9999 -O2


Accidentaly I found out that using

  firefox -safe-mode

makes the clang compiles stable - dromaeo.com tests finish without segfaulting.  I then thought that some extensions in my profile might have caused the segfaulting behavior, so the profile was backuped and

  rm -rf ~/.mozilla

was called to have FF create a fresh profile on start.  However, even with a fresh profile created (no extensions in effect), dromaeo.com makes clang-FF segfault.  I noticed that -safe-mode also sets the locale to en, so I gave

  firefox -UIlocale en

a try, presuming that maybe just the de locale was an issue.  It was not, FF reproducably segfaulted.  The only chance of completing dromaeo.com tests with the [unstable]-marked FF builds above, was to use

  firefox -safe-mode
  -safe-mode         Disables extensions and themes for this session.

The description of this option does not seem to be exhaustive.  A fresh profile, with neither extensions or themes installed, segfaults as well, so this cannot be the same as using -safe-mode.  Presumably there are other things turned off internally if this option is in effect.  This might help to narrow down why clang-FF segfaults without it.


Greetings
Comment 6 cmuelle8 2013-03-23 14:42:50 UTC
(In reply to comment #5)
> (In reply to comment #3)
> > - this is for an "-O2" build with clang-9999, elfhack enabled, lto disabled
> > 
> Presumably there are other
> things turned off internally if this option is in effect.  This might help
> to narrow down why clang-FF segfaults without it.

There is a more comprehensive set of what is turned off here:

  http://kb.mozillazine.org/Safe_mode

"JIT JS compiler" is disabled in safe-mode, so a good guess is that the clang builds segfault somewhere in the JIT code of FF.  If jit-js may be compiled and tested stand-alone, this might reduce the problem.  Compiling only that part of the source with gcc might help drill down to the clang-offending source file.
Comment 7 cmuelle8 2013-03-23 16:31:28 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #3)
> > > - this is for an "-O2" build with clang-9999, elfhack enabled, lto disabled
> > This might help to narrow down why clang-FF segfaults without it.
>   http://kb.mozillazine.org/Safe_mode
> "JIT JS compiler" is disabled in safe-mode

- this is a stacktrace for an "-g -O2" build with clang-9999, elfhack enabled, lto disabled

Program received signal SIGSEGV, Segmentation fault.
JS::CallReceiver::callee (this=0x7fffffff8790) at ../../../dist/include/jsapi.h:1384
1384    ../../../dist/include/jsapi.h: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  JS::CallReceiver::callee (this=0x7fffffff8790) at ../../../dist/include/jsapi.h:1384
#1  0x00007ffff60e829c in js::ContextStack::getFixupFrame (this=0x7fffd020c598, 
    cx=0x7fffd020c4f0, report=js::DONT_REPORT_ERROR, args=..., fun=0x7fffcf5fab80, 
    script=0x7fffcf5f5640, ncode=0x7fffffff8790, initial=(unknown: 718596888), 
    stackLimit=0x7ffff7e6db70)
    at /var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/js/src/vm/Stack-inl.h:498
#2  0x00007ffff60e80e6 in js::mjit::stubs::FixupArity (f=..., nactual=4158481088)
    at /var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/js/src/methodjit/InvokeHelpers.cpp:212
#3  0x00007fffd9a38c03 in ?? ()
#4  0x00007fffd9a39b4d in ?? ()
#5  0x0000000000000000 in ?? ()
(gdb) quit


Any ideas?
Comment 8 cmuelle8 2013-03-24 02:00:37 UTC
Using
  about:config

to set
  javascript.options.methodjit.chrome;false
  javascript.options.methodjit.content;false

helps, so the problem definitely seems to be in methodjit.  Atm methodjit can be turned off directly in the FF ebuild.



Another thing I noticed is
  mozilla-release/config.guess and
  mozilla-release/js/src/config.guess

might produce wrong results wrt to the Gentoo ebuild.  The ebuild sets TARGET and BUILD to the CHOST of make.conf, respectively paludis/bashrc.  This is a problem, since the configure toolchain of FF detects crosscompilation via test TARGET != HOST.

E.g. if you have
  CHOST=x86_64-pc-linux-gnu

set in your make.conf or bashrc this will conflict with the output of
  mozilla-release/build/autoconf/config.guess and
  mozilla-release/js/src/build/autoconf/config.guess

which for the example host would be
  CHOST=x86_64-unknown-linux-gnu

The ebuild uses CHOST as an option to --target and --build, but not --host.  The configure happens twice, i.e. js/src/configure is called from within configure in the top level directory, so when "cross-compilation" is wrongly detected in js/src/configure, because of
  x86_64-unknown-linux-gnu != x86_64-pc-linux-gnu

the CC and CXX are determined differently than for the calling configure.  One ends up compiling the top level dir with "clang", and js/src with "gcc" because this is the first matching default js/src/configure tests against.

There are two ways to solve this - either leave out or adjust -target and -build in the /ebuild/ to match the output of
  mozilla-release/config.guess

or let the ebuild (eventually euser_)patch
  mozilla-release/client.mk

--- mozilla-release/client.mk           2013-03-07 11:48:37.000000000 +0100
+++ mozilla-release/client.mk.new       2013-03-24 00:07:26.531818896 +0100
@@ -75,6 +75,9 @@
 
 CONFIG_GUESS_SCRIPT := $(wildcard $(TOPSRCDIR)/build/autoconf/config.guess)
 ifdef CONFIG_GUESS_SCRIPT
+  # these need to be in sync, so change them in sync
+  CONFIG_GUESS := $(shell echo -e "\#!/bin/sh\necho $${CHOST}" > $(CONFIG_GUESS_SCRIPT))
+  CONFIG_GUESS := $(shell echo -e "\#!/bin/sh\necho $${CHOST}" > $(subst build,js/src/build,$(CONFIG_GUESS_SCRIPT)))
   CONFIG_GUESS := $(shell $(CONFIG_GUESS_SCRIPT))
 endif
 
On x86 this bug does not surface, since config.guess produces *-pc-* for i*86 hosts afa i've seen.  Using this patch one can be sure that the mozilla toolchain does not accidentaly detect cross-compilation.  Btw, this false detection happens with CC=gcc as well, but it's less a problem, since the default HOST_CC picked in js/src when cross-compiling is again gcc, but this is not, as should be, determined by the ENVironment passed.  The patch irons out this problem on x86_64 and theoretically should on all other archs as well, as echoing CHOST from config.guess harmonizes with the values given in the ebuild.

The environment of CC CXX vars carefully set up in mozialla-release/configure is used in js/src if cross-compilation is not detected, this is how it's intended if you're not indeed cross-compiling..


Greetings
Comment 9 cmuelle8 2013-03-24 15:45:24 UTC
Created attachment 343108 [details, diff]
firefox-19.0.2-clang-and-config.guess.patch

patches elfhack, debug flags, mssse3 detection issue, config.guess to compile with clang  (update, includes the patch listed in comment #8

files effected:

mozilla-release/build/unix/elfhack/Makefile.in
mozilla-release/js/src/configure.in
mozilla-release/configure.in
mozilla-release/client.mk

mozilla-release/build/autoconf/config.guess
mozilla-release/js/src/build/autoconf/config.guess
Comment 10 cmuelle8 2013-03-24 15:51:47 UTC
Created attachment 343112 [details, diff]
firefox-19.0.2.ebuild.patch

patch ebuild to

- account for know jit segfault/bug (--disable-methodjit)
- enable-address-sanitizer
- enable-llvm-hacks
- not modify some flags (-mno-avx, -fno-stack-protector) that are set depending on gcc-version
(if clang is used)

- keep prior behavior
(if clang is not used)


- respect EXTRA_ECONF (harmonize with other ebuilds), so gentoo users may use EXTRA_ECONF to pass options to the FF configure's
(for all compilers)


Greetings
Comment 11 cmuelle8 2013-03-24 20:23:09 UTC
(In reply to comment #4)
> Created attachment 342926 [details]
> paludis/cave build log of firefox build using gcc-4.7.2 -O2 -flto
> 
> The test series omits results for an gcc "-O2 -flto" build.  Trying this,
> compilation interrupted with an error linking jsheaptools, see attachment
> for full build log.

There is a metabug for this problem here
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375

with minimum patches to gcc needed here
  http://gcc.gnu.org/bugzilla/attachment.cgi?id=23364

So this is not a FF issue, a successful LTO build will depend on a gcc containing these patches, i.e.
  >sys-devel/gcc-4.7.2-r1

with a minimum gcc version yet to be found.  For the scope of FF compile on gentoo it probably makes sense to defer searching this route until the depends of this metabug are closed..
Comment 12 cmuelle8 2013-03-24 20:31:52 UTC
Applying the attached patches, an imho most promising, debugging issue to get a more performant FF on Gentoo/amd64 remains:

  How to iron out FF segfaults if --enable-methodjit is used with clang?

So far, neither
  --enable-llvm-hacks

nor both
  --enable-address-sanitizer
  --enable-llvm-hacks

seem to influence this bug.  Any ideas?
Comment 13 cmuelle8 2013-03-25 15:57:34 UTC
(In reply to comment #12)
>   How to iron out FF segfaults if --enable-methodjit is used with clang?

"And now for sth completely different.."
It turns out that there is a way to enable a stable jit with clang compiles.  



With the current patch, if clang is used, I feed
  --disable-methodjit
  --enable-tracejit

to .mozconfig which compiles and runs fine, but apparently does not use tracejit or any js jit at all, as it leads to a mediocre
  ~68 runs/s on 3D-Mesh dromaeo.com test



Comparing this to the non-LTO -O2 gcc build referenced above which resulted in
  ~1438 runs/s on 3D-Mesh dromaeo.com test

leads to the presumption that tracejit probably depends on methodjit to function, so presumably we cannot disable it, if we want jit to work.



For tests I went back to feed both
  --enable-methodjit
  --enable-tracejit

to clang compiles, which reproducably returned the segfaults described above.  So, in about:config I set
  javascript.options.methodjit.content;false
  javascript.options.methodjit.chrome;false
   (for --enable-methodjit compiles these are turned on by default in
    mozilla-release/modules/libpref/src/init/all.js)

Having done this, I redid js-tests on my LTO -O4 clang build, resulting in a whopping
  ~1530 runs/s on 3D-Mesh dromaeo.com test



How is that?  My explanation for this strange behavior currently is, that tracejit is used at _run time_ if methodjit is turned off in "about-config".  However, at _compile time_ methodjit needs to be enabled, else all of jit, including tracejit, is dead code ot not even compiled in.



May someone please confirm this on another box?  Also, writing this using the current clang -O4 build, I notice sluggish UI behavior.  E.g. the menus switch a little slower than in gcc build, so I guess it's not a full success story yet.  However, it's getting there..

In conclusion, if you want to confirm the dromaeo.com results, do
- apply the two patches, follow along comment #1
- edit the patched ebuild, replace "disable-methodjit" by "enable-methodjit"
- do a clang build
- run firefox and set
    javascript.options.methodjit.content;false
    javascript.options.methodjit.chrome;false
- run dromaeo.com tests



If the UI things are solved this turns out to be a viable alternative to a gcc build, as we can easily change the methodjit defaults in
  mozilla-release/modules/libpref/src/init/all.js
by adding the change to the user patch attached.


Greetings
Comment 14 cmuelle8 2013-03-25 21:24:35 UTC
(In reply to comment #13)
> the current clang -O4 build, I notice sluggish UI behavior.  E.g. the menus
> switch a little slower than in gcc build,

update:  This must have been subjective, cross-checking with a gcc build after that did not show any difference.  Might have had to do with a cairo rebuild in between, but it's definitely not FF related or worth searching for..

So the only insight not yet included in the attached patches is the methodjit curiosity, somebody please confirm this.

Thanks
Comment 15 cmuelle8 2013-03-27 11:57:22 UTC
(In reply to comment #13)
> How is that?  My explanation for this strange behavior currently is, that
> tracejit is used at _run time_ if methodjit is turned off in "about-config".
[...]
> May someone please confirm this on another box?

Meanwhile I was able to produce a clang (from trunk) build using -O2 on an i686-pc-linux-gnu box running on atom n270, see
  https://bugzilla.mozilla.org/show_bug.cgi?id=854936

The build does not segfault like on x86_64-pc-linux-gnu, i.e. it's not necessary to turn of methodjit in about:config.  dromaeo.com results are decent for an atom, I guess
  http://dromaeo.com/?id=192620

I suppose it's an arch dependent problem..
Comment 16 Randy Andy 2013-03-28 17:40:52 UTC
Hi all.

I'm also not able to build firefox-19.0.2 here on my i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz with 1GB RAM and 4GB swap.
Have been built/installed version 19.0 fine since 24.02.2013 instead.

No LTO config on this box, here some more details, please tell if you need more here, or should I open a new different report for this:

 * Running elibtoolize in: mozilla-release/modules/freetype2/builds/unix/
...skipping...
>, js::DefaultHasher<js::StackFrame*>, js::RuntimeAllocPolicy>::MapHashPolicy, js::RuntimeAllocPolicy>::Ptr::entry' was declared here
i686-pc-linux-gnu-g++ -o Stack.o -c  -I./../../dist/system_wrappers_js -include /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/config/gcc_hidden.h -DENABLE_TYPEDARRAY_MOVE -DENABLE_YARR_JIT=1 -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_SUPPORT -DEXPORT_JS_API -DJS_HAS_CTYPES -DDLL_PREFIX=\"lib\" -DDLL_SUFFIX=\".so\" -DUSE_ZLIB -I/usr/lib/libffi-3.0.13/include  -I.  -I/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/../../mfbt/double-conversion -I/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src -I. -I./../../dist/include  -I/usr/include/nspr      -I/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src -I/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/assembler -I/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/yarr  -fPIC  -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Werror=conversion-null -Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align -march=atom -pipe -mno-avx -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -pthread -pipe  -DNDEBUG -DTRIMMED -g -O2 -fomit-frame-pointer -DUSE_SYSTEM_MALLOC=1 -DENABLE_ASSEMBLER=1 -DENABLE_JIT=1   -DMOZILLA_CLIENT -include ./js-confdefs.h -MD -MF .deps/Stack.o.pp  /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/vm/Stack.cpp
String.cpp
In file included from /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/jsatom.h:22:0,
                 from /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/jscntxt.h:21,
                 from /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/vm/Debugger.h:15,
                 from /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/vm/Debugger.cpp:8:
/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/gc/Barrier.h: In static member function 'static bool js::Debugger::slowPathOnLeaveFrame(JSContext*, bool)':
/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/gc/Barrier.h:173:34: warning: '*((void*)(& r)+16).js::detail::HashTable<js::HashMapEntry<js::StackFrame*, js::RelocatablePtr<JSObject> >, js::HashMap<js::StackFrame*, js::RelocatablePtr<JSObject>, js::DefaultHasher<js::StackFrame*>, js::RuntimeAllocPolicy>::MapHashPolicy, js::RuntimeAllocPolicy>::Ptr::entry' may be used uninitialized in this function [-Wmaybe-uninitialized]
/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/vm/Debugger.cpp:576:21: note: '*((void*)(& r)+16).js::detail::HashTable<js::HashMapEntry<js::StackFrame*, js::RelocatablePtr<JSObject> >, js::HashMap<js::StackFrame*, js::RelocatablePtr<JSObject>, js::DefaultHasher<js::StackFrame*>, js::RuntimeAllocPolicy>::MapHashPolicy, js::RuntimeAllocPolicy>::Ptr::entry' was declared here
In file included from /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/jsatom.h:22:0,
                 from /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/jscntxt.h:21,
                 from /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/vm/Debugger.h:15,
                 from /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/vm/Debugger.cpp:8:
/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/gc/Barrier.h:173:34: warning: '*((void*)(& r)+16).js::detail::HashTable<js::HashMapEntry<js::StackFrame*, js::RelocatablePtr<JSObject> >, js::HashMap<js::StackFrame*, js::RelocatablePtr<JSObject>, js::DefaultHasher<js::StackFrame*>, js::RuntimeAllocPolicy>::MapHashPolicy, js::RuntimeAllocPolicy>::Ptr::entry' may be used uninitialized in this function [-Wmaybe-uninitialized]
/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/vm/Debugger.cpp:525:21: note: '*((void*)(& r)+16).js::detail::HashTable<js::HashMapEntry<js::StackFrame*, js::RelocatablePtr<JSObject> >, js::HashMap<js::StackFrame*, js::RelocatablePtr<JSObject>, js::DefaultHasher<js::StackFrame*>, js::RuntimeAllocPolicy>::MapHashPolicy, js::RuntimeAllocPolicy>::Ptr::entry' was declared here
/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/vm/Stack.cpp: In member function 'js::StackIter& js::StackIter::operator++()':
/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/vm/Stack.cpp:1541:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugs.gentoo.org/> for instructions.
{standard input}: Assembler messages:
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
make[5]: *** [Stack.o] Error 1
make[5]: *** Waiting for unfinished jobs....
make[5]: Leaving directory `/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/obj-i686-pc-linux-gnu/js/src'
make[4]: *** [libs_tier_js] Error 2
make[4]: Leaving directory `/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/obj-i686-pc-linux-gnu'
make[3]: *** [tier_js] Error 2
make[3]: Leaving directory `/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/obj-i686-pc-linux-gnu'
make[2]: *** [default] Error 2
make[2]: Leaving directory `/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/obj-i686-pc-linux-gnu'
make[1]: *** [realbuild] Error 2
make[1]: Leaving directory `/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release'
make: *** [build] Error 2
emake failed
 * ERROR: www-client/firefox-19.0.2 failed (compile phase):
 *   emake failed
 * 
 * Call stack:
 *     ebuild.sh, line  93:  Called src_compile
 *   environment, line 4882:  Called die
 * The specific snippet of code:
 *           CC="$(tc-getCC)" CXX="$(tc-getCXX)" LD="$(tc-getLD)" MOZ_MAKE_FLAGS="${MAKEOPTS}" emake -f client.mk || die "emake failed";
 * 
 * If you need support, post the output of `emerge --info '=www-client/firefox-19.0.2'`,
 * the complete build log and the output of `emerge -pqv '=www-client/firefox-19.0.2'`.
 * The complete build log is located at '/var/tmp/portage/www-client/firefox-19.0.2/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/www-client/firefox-19.0.2/temp/environment'.
 * Working directory: '/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release'
 * S: '/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release


_________________________________________________________________________


emerge --info =www-client/firefox-19.0.2
Portage 2.2.0_alpha169 (default/linux/x86/13.0/desktop/kde, gcc-4.7.2, glibc-2.16.0, 3.7.10-gentoo i686)
=================================================================
                         System Settings
=================================================================
System uname: Linux-3.7.10-gentoo-i686-Intel-R-_Atom-TM-_CPU_N270_@_1.60GHz-with-gentoo-2.2
KiB Mem:     1020168 total,    729436 free
KiB Swap:    4094972 total,   4094972 free
Timestamp of tree: Wed, 27 Mar 2013 17:00:01 +0000
ld GNU ld (GNU Binutils) 2.23.2
distcc 3.1 i686-pc-linux-gnu [disabled]
app-shells/bash:          4.2_p45
dev-java/java-config:     2.1.12-r1
dev-lang/python:          2.7.3-r3, 3.2.3-r2
dev-util/cmake:           2.8.10.2-r1
dev-util/pkgconfig:       0.28
sys-apps/baselayout:      2.2
sys-apps/openrc:          0.11.8
sys-apps/sandbox:         2.6-r1
sys-devel/autoconf:       2.13, 2.69
sys-devel/automake:       1.9.6-r3, 1.11.6, 1.13.1
sys-devel/binutils:       2.23.2
sys-devel/gcc:            4.7.2-r1
sys-devel/gcc-config:     1.8
sys-devel/libtool:        2.4.2
sys-devel/make:           3.82-r4
sys-kernel/linux-headers: 3.8 (virtual/os-headers)
sys-libs/glibc:           2.16.0
Repositories: gentoo
Installed sets: @system
ACCEPT_KEYWORDS="x86 ~x86"
ACCEPT_LICENSE="*"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=atom -O2 -fomit-frame-pointer -pipe -mfpmath=sse"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/polkit-1/actions"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=atom -O2 -fomit-frame-pointer -pipe -mfpmath=sse"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--quiet-build=n --keep-going --autounmask-write"
FCFLAGS="-O2 -march=i686 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
FFLAGS="-O2 -march=i686 -pipe"
GENTOO_MIRRORS="http://gentoo.tiscali.nl/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/"
LANG="de_DE.UTF-8"
LC_ALL=""
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="7Zip X a52 aac aalib acl acpi akonadi alsa apng asf audiofile bash-completion berkdb branding bzip2 cairo cdda cdr cjk cli consolekit cracklib crypt css cups cxx dbus declarative dga dhcpcd djvu dlloader dri drm dts dv dvd dvdr dvdread dvi emboss enca encode exif extras fame fat ffmpeg fftw firefox firefox3 flac flash fontconfig fortran ftp g3dvl gallium gbm gdbm gif git gles gles1 gles2 glib gphoto2 gpm graphviz gs gstreamer gtk iconv icq imap intel ipv6 irc jabber java jpeg kde kexiv2 kipi kpathsea lame laptop lcms ldap lensfun libcaca libclamav libnotify libsamplerate libv4l libv4l2 liemikuutio lirc live llvm lm_sensors lzma lzo mad mainmenuhooks matroska metric minizip mjpeg mmx mng modemmanager modules mp3 mp4 mpeg mplayer msn mudflap musepack mysql nas ncurses network networkmanager nfsv4 nfsv41 nls nptl nsplugin nss ntfs ntp ogg ogm okular openal opengl openmp openssl openstreetmap openvg optimization opus osdmenu osmesa pam pango parted pastebin pcm pcre pdf pdfimport phonon plasma player plugin pm-utils pmu png pnm policykit pop postproc ppds ppp prison privacy python python3 qalculate qt qt3support qt4 quicktime rar raw readline recode recording redeyes rle rss rtmp rtsp scanner schroedinger script sdk sdl sdl-image sdl-sound secure-delete semantic-desktop server session sftp shine shorten shout sift skype smp sms sna sndfile soundextract speech speex spell sql sse sse2 ssl ssse3 startup-notification stk stream strigi svg syncearly tcpd templates tga theora threads thumbnail tiff toolame tools transcode tremor truetype twolame udev udisks umfpack unicode upower urlpicpreview usb utils v4l v4l2 vaapi vamp vcd vcdinfo vcdx video virtuoso vlm vorbis vpx vxml wav wavpack webcam webdav webkit webpresence win32codecs winbind windeco wma wma-fixed wmf wxwidgets x264 x86 xanim xcb xcomposite xine xinerama xml xorgmodule xpm xprint xscreensaver xsl xslt xv xvid xvmc xwax_decoders_aac xwax_decoders_cd xwax_decoders_flac xwax_decoders_misc xwax_decoders_mp3 xwax_decoders_ogg yaepg yahoo youtube yv12 zip zlib" ABI_X86="32" ALSA_CARDS="hda-intel loopback virmidi" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="*" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="de" LIRC_DEVICES="devinput" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="intel i915" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Comment 17 cmuelle8 2013-03-28 18:09:33 UTC
(In reply to comment #16)
> Hi all.
> 
> I'm also not able to build firefox-19.0.2 here on my i686 Intel(R) Atom(TM)
> CPU N270 @ 1.60GHz with 1GB RAM and 4GB swap.
> Have been built/installed version 19.0 fine since 24.02.2013 instead.
> 

Thanks for reporting, you most probably hit bug #461694 - it's an optimization bug in gcc-4.7.2-r1 with regard to atom arch.  It's well debuged thanks to one of the toolchain maintainers and might be fixed in next gcc version.  Reportedly using gcc-4.6.3 is ok, but I did not try that myself.

This bug is (mainly) about compiling FF with clang - you're using gcc, so either
  open a new bug if you think you have a different issue or
  append to bug #461694 if you've additional information.



As for this bug I'm looking for someone who can confirm that /not/ disabling methodjit makes the clang compile segfault, while turning methodjit off in about:config of that same segfaulting build makes it work.


Greetings
Comment 18 cmuelle8 2013-03-28 18:12:39 UTC
(In reply to comment #17)
> As for this bug I'm looking for someone who can confirm that /not/ disabling
> methodjit makes the clang compile segfault, while turning methodjit off in
> about:config of that same segfaulting build makes it work.

Please read comment #13 if you want to help with this - you probably need an x86_64 arch, since I crossed check on x86 which does not show the same behavior.

Thanks
Comment 19 Randy Andy 2013-03-29 13:05:14 UTC
Thanks for your fast respond and sorry for my delayed answer.

It takes lot of time to build the already deleted gcc-4.6.3 again on my atom pc and than to recompile firefox to give a positive statement, but I will do so in your referenced report.

Regarding your call for testing and #13.
I won't try that on my x86_64 Box, cause I'm not using clang.
Comment 20 cmuelle8 2013-03-30 22:53:53 UTC
Created attachment 343798 [details]
firefox-19.0.2.ebuild.patch

Update ebuild patch based on gathered knowledge

- correct usage of address-sanitizer
- patch methodjit in run-time options to false, only on x86_64

See
  https://developer.mozilla.org/en-US/docs/Building_Firefox_with_Address_Sanitizer#Adjusting_the_build_configuration
  https://bugzilla.mozilla.org/show_bug.cgi?id=854936

for details.
Comment 21 cmuelle8 2013-03-30 22:57:44 UTC
Created attachment 343800 [details, diff]
firefox-19.0.2.ebuild.patch

retab patch (fix messed up whitespace..)
Comment 22 cmuelle8 2013-04-01 21:22:38 UTC
Created attachment 344010 [details, diff]
/etc/portage/patches/www-client/firefox-19.0.2/firefox-19.0.2-clang-3.3svn.patch

Newest clang from trunk seems to have stricter namespace checking.  Adding the following namespace prefixes was required to get a clean compile with clang from trunk.  The patch reflects those changes.

-        sp->init(comp, this->asObjectPtr(), offset++, UndefinedValue());
+        sp->init(comp, this->asObjectPtr(), offset++, JS::UndefinedValue());

-        sp->init(comp, this->asObjectPtr(), offset++, UndefinedValue());
+        sp->init(comp, this->asObjectPtr(), offset++, JS::UndefinedValue());
 
-    AutoAssertNoGC nogc;
+    JS::AutoAssertNoGC nogc;


Also moved out config.guess patch, it's now in bug #462488  Up to now, using the patches from that and this bug, I was able to produce and stably run builds on x86 and x86_64.
Comment 23 cmuelle8 2013-04-06 13:01:32 UTC
Created attachment 344638 [details, diff]
/etc/portage/patches/www-client/firefox-21.0/firefox-21.0-clang-3.3svn.patch

For the transition from FF 19.0.2 to FF 20.0 a small addition was appended to the previous patch regarding file
  mozilla-release/js/src/jspropertycacheinlines.h

@@ -64,7 +64,7 @@
 js::PropertyCache::testForSet(JSContext *cx, jsbytecode *pc, JSObject *obj,
                               PropertyCacheEntry **entryp, JSObject **obj2p, PropertyName **namep)
 {
-    AutoAssertNoGC nogc;
+    JS::AutoAssertNoGC nogc;
 
     JS_ASSERT(this == &cx->propertyCache());
Comment 24 cmuelle8 2013-04-06 13:03:07 UTC
Created attachment 344640 [details, diff]
firefox-20.0.1.ebuild.patch
Comment 25 cmuelle8 2013-06-18 22:09:12 UTC
Comment on attachment 344638 [details, diff]
/etc/portage/patches/www-client/firefox-21.0/firefox-21.0-clang-3.3svn.patch

update to new rev - renaming sufficed, codebase wrt patch unchanged
Comment 26 cmuelle8 2013-06-18 22:12:16 UTC
Created attachment 351352 [details, diff]
firefox-21.0.ebuild.patch

ion seems to have the same problem as methodjit when compiled with clang - segfaults FF unless disabled

remaining changes to a large extent identical to the ones for 20.0.1
Comment 27 cmuelle8 2013-06-23 18:57:03 UTC
Created attachment 351766 [details, diff]
firefox-21.0.ebuild.patch

fix js headers patch that did not apply correctly since 21.0
Comment 28 cmuelle8 2013-06-23 19:00:28 UTC
Created attachment 351768 [details, diff]
/etc/portage/patches/www-client/firefox-21.0/firefox-21.0-clang-3.4svn.patch
Comment 29 Jory A. Pratt gentoo-dev 2013-06-23 19:40:59 UTC
All you experimental changes with clang and using -9999 is not gonna be supported by gentoo developers. You can file bugs with upstream if you would like things fixed.
Comment 30 cmuelle8 2013-06-23 22:46:13 UTC
You're funny.  Upstream uses clang builds since long, it's just the gentoo ebuilds/eclasses that do not support it.  Also as a mozilla maintainer you should know that upstream does not fix released versions, you can be happy if some dev fishes out your bug there to fix in trunk.

Since the changeset more or less survived four different versions now, it is pretty robust to incorporate, it's also needed for clang 3.3 now in tree as testing.

but where there is no will, there's no way. you've made your point.  just leave it open for other experimental natures seeking help.

if you ever feel different about it, my offer maintaining these changes until they're fully obsoleted by a release in the future still stands.

take care.
Comment 31 Ian Stakenvicius (RETIRED) gentoo-dev 2013-06-24 13:32:34 UTC
(In reply to cmuelle8 from comment #30)
> You're funny.  Upstream uses clang builds since long, it's just the gentoo
> ebuilds/eclasses that do not support it.  Also as a mozilla maintainer you
> should know that upstream does not fix released versions, you can be happy
> if some dev fishes out your bug there to fix in trunk.
> 


If upstream accepts the patches and integrates them into HEAD, then we do maintain them via backporting.  I'm sure if you can push to get the clang changes you want into the mozilla build system (ie attachment 351768 [details, diff]) via upstream, then official gentoo support is much more likely.
Comment 32 cmuelle8 2013-07-05 05:12:05 UTC
Created attachment 352652 [details, diff]
/etc/portage/patches/www-client/firefox/firefox-24.0-clang-3.x.patch

- patching jspropertycacheinlines.h is not necessary with FF 22.0, patch reduced
- moving mssse3 detection and the debug flag logic still not fixed in trunk
- ion and methodjit still disabled with clang by default - please enable and test stability using about:config in FF's address bar - report back if you spare some time
Comment 33 cmuelle8 2013-07-05 05:15:09 UTC
Created attachment 352654 [details, diff]
firefox-22.0.ebuild.patch

patch against stock ebuild in tree
Comment 34 cmuelle8 2013-07-05 05:22:59 UTC
(In reply to cmuelle8 from comment #33)
> Created attachment 352654 [details, diff] [details, diff]
> firefox-22.0.ebuild.patch
> 
> patch against stock ebuild in tree

While I had some issues compiling FF 21.0 with clang on gentoo unsolved by the supplied patches, 22.0 compiles and runs fine again.  So the following issue is gone and solved in 22.0.

=========[PROBLEM-LOG of 21.0, SOLVED in 22.0]
[...]
In file included from /var/tmp/paludis/www-client-firefox-21.0/work/mozilla-release/js/src/jsstr.cpp:20:
./../../dist/include/mozilla/CheckedInt.h:186:31: error: const_cast to 'bool', which is not a reference, pointer-to-object, or pointer-to-data-member
    static const bool value = const_cast<bool>(IntegerType(-1) <= IntegerType(0));
                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./../../dist/include/mozilla/CheckedInt.h:294:27: note: in instantiation of template class 'mozilla::detail::IsSigned<unsigned int>' requested here
         bool IsTSigned = IsSigned<T>::value,
                          ^
./../../dist/include/mozilla/CheckedInt.h:350:10: note: in instantiation of default argument for 'IsInRangeImpl<unsigned int, unsigned long>' required here
  return IsInRangeImpl<T, U>::run(x);
         ^~~~~~~~~~~~~~~~~~~
./../../dist/include/mozilla/CheckedInt.h:574:26: note: in instantiation of function template specialization 'mozilla::detail::IsInRange<unsigned int, unsigned long>' requested here
        mIsValid(detail::IsInRange<T>(value))
                         ^
/var/tmp/paludis/www-client-firefox-21.0/work/mozilla-release/js/src/jsstr.cpp:2097:35: note: in instantiation of function template specialization 'mozilla::CheckedInt<unsigned int>::CheckedInt<unsigned long>' requested here
    CheckedInt<uint32_t> replen = repstr->length();
                                  ^
In file included from /var/tmp/paludis/www-client-firefox-21.0/work/mozilla-release/js/src/jsstr.cpp:20:
./../../dist/include/mozilla/CheckedInt.h:186:31: error: const_cast to 'bool', which is not a reference, pointer-to-object, or pointer-to-data-member
    static const bool value = const_cast<bool>(IntegerType(-1) <= IntegerType(0));
                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./../../dist/include/mozilla/CheckedInt.h:295:27: note: in instantiation of template class 'mozilla::detail::IsSigned<unsigned long>' requested here
         bool IsUSigned = IsSigned<U>::value,
                          ^
./../../dist/include/mozilla/CheckedInt.h:350:10: note: in instantiation of default argument for 'IsInRangeImpl<unsigned int, unsigned long, false>' required here
  return IsInRangeImpl<T, U>::run(x);
         ^~~~~~~~~~~~~~~~~~~
./../../dist/include/mozilla/CheckedInt.h:574:26: note: in instantiation of function template specialization 'mozilla::detail::IsInRange<unsigned int, unsigned long>' requested here
        mIsValid(detail::IsInRange<T>(value))
                         ^
/var/tmp/paludis/www-client-firefox-21.0/work/mozilla-release/js/src/jsstr.cpp:2097:35: note: in instantiation of function template specialization 'mozilla::CheckedInt<unsigned int>::CheckedInt<unsigned long>' requested here
    CheckedInt<uint32_t> replen = repstr->length();
                                  ^
2 errors generated.
make[5]: Leaving directory `/var/tmp/paludis/www-client-firefox-21.0/work/mozilla-release/obj-x86_64-unknown-linux-gnu/js/src'
make[5]: *** [jsstr.o] Error 1
make[4]: *** [libs_tier_js] Error 2
=========
Comment 35 cmuelle8 2013-07-05 05:27:31 UTC
Created attachment 352656 [details]
build log showing clang linking error, if ssse3 detection is not moved in configure.in

A proper solution needs to determine the availablity of ssse3 using clang, like it is done for gcc builds.  However, the configure test tailored for gcc does not play well with clang, shown by the build log.


Greetings
Comment 36 cmuelle8 2013-07-09 03:20:57 UTC
Created attachment 352898 [details, diff]
firefox-22.0.ebuild.patch

Note:

- FF 22.0 + clang does not segfault dromaeo.com tests anymore, when methodjit is enabled, same applies to ion js engine -> reflect this in firefox-22.0.ebuild.patch

- I had a weird upgrade bug:  After emerging/paluding FF22.0 successfully and starting FF, pages would not load - typing a site in the address bar and using web dev tools pane, network log said "GET <any-site.us>" and nothing happened.  A couple of seconds later FF responds with the usual "network connectivity problem" page.  However, I upgraded on amd64 and x86, and this behavior was only observed on amd64.
-> Using a fresh profile, renaming the old as backup, solved this problem.
-> I imported bookmarks from the backuped profile and installed a couple of addons into the fresh profile and deleted the old one.

-> If this happens to you, either rename old profile or please investigate further into this if you have the merits to do so.  Report back if you can.  However, I suspect this was due to an error specific to my profile as I couldn't reproduce it on another machine.

Greetings
Comment 37 cmuelle8 2013-10-22 14:01:45 UTC
Created attachment 361618 [details, diff]
firefox-24.0-r1.ebuild.patch
Comment 38 cmuelle8 2013-10-22 15:40:25 UTC
Created attachment 361630 [details, diff]
/etc/portage/patches/www-client/firefox/firefox-24.0-clang-3.x.patch
Comment 39 cmuelle8 2013-10-22 15:48:35 UTC
(In reply to cmuelle8 from comment #37)
> Created attachment 361618 [details, diff] [details, diff]
> firefox-24.0-r1.ebuild.patch

Latest clang from trunk has a problem with MOZINLINEs, so you might have to disable-replace-malloc / disable-jemalloc and comment out jemalloc export in the ebuild.

Here are the errors I got

clang++ -o mozalloc.o -c   -DXP_LINUX -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_SUPPORT -I../../xpcom -I/var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc -I. -I../../dist/include  -I/usr/include/nspr -I/usr/include/nss      -fPIC -Qunused-arguments  -Qunused-arguments -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wsign-compare -Wno-invalid-offsetof -Wno-c++0x-extensions -Wno-extended-offsetof -Wno-unknown-warning-option -Wno-return-type-c-linkage -Wno-mismatched-tags -march=native -pipe -fomit-frame-pointer -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -std=gnu++0x -pthread -pipe  -DNDEBUG -DTRIMMED -O4 -fomit-frame-pointer  -Qunused-arguments  -DMOZILLA_CLIENT -include ../../mozilla-config.h -MD -MP -MF .deps/mozalloc.o.pp  /var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc/mozalloc.cpp
clang: warning: -O4 is equivalent to -O3
In file included from /var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc/mozalloc.cpp:29:
../../dist/include/mozilla/mozalloc.h:198:21: error: replacement function 'operator new' cannot be declared 'inline'
MOZALLOC_EXPORT_NEW MOZALLOC_INLINE
                    ^
../../dist/include/mozilla/mozalloc.h:44:27: note: expanded from macro 'MOZALLOC_INLINE'
#  define MOZALLOC_INLINE MOZ_ALWAYS_INLINE_EVEN_DEBUG
                          ^
../../dist/include/mozilla/Attributes.h:42:75: note: expanded from macro 'MOZ_ALWAYS_INLINE_EVEN_DEBUG'
#  define MOZ_ALWAYS_INLINE_EVEN_DEBUG     __attribute__((always_inline)) MOZ_INLINE
                                                                          ^
../../dist/include/mozilla/Attributes.h:20:33: note: expanded from macro 'MOZ_INLINE'
#  define MOZ_INLINE            inline
                                ^
In file included from /var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc/mozalloc.cpp:29:
../../dist/include/mozilla/mozalloc.h:204:21: error: replacement function 'operator new' cannot be declared 'inline'
MOZALLOC_EXPORT_NEW MOZALLOC_INLINE
                    ^
../../dist/include/mozilla/mozalloc.h:44:27: note: expanded from macro 'MOZALLOC_INLINE'
#  define MOZALLOC_INLINE MOZ_ALWAYS_INLINE_EVEN_DEBUG
                          ^
../../dist/include/mozilla/Attributes.h:42:75: note: expanded from macro 'MOZ_ALWAYS_INLINE_EVEN_DEBUG'
#  define MOZ_ALWAYS_INLINE_EVEN_DEBUG     __attribute__((always_inline)) MOZ_INLINE
                                                                          ^
../../dist/include/mozilla/Attributes.h:20:33: note: expanded from macro 'MOZ_INLINE'
#  define MOZ_INLINE            inline
                                ^
In file included from /var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc/mozalloc.cpp:29:
../../dist/include/mozilla/mozalloc.h:210:21: error: replacement function 'operator new[]' cannot be declared 'inline'
MOZALLOC_EXPORT_NEW MOZALLOC_INLINE
                    ^
../../dist/include/mozilla/mozalloc.h:44:27: note: expanded from macro 'MOZALLOC_INLINE'
#  define MOZALLOC_INLINE MOZ_ALWAYS_INLINE_EVEN_DEBUG
                          ^
../../dist/include/mozilla/Attributes.h:42:75: note: expanded from macro 'MOZ_ALWAYS_INLINE_EVEN_DEBUG'
#  define MOZ_ALWAYS_INLINE_EVEN_DEBUG     __attribute__((always_inline)) MOZ_INLINE
                                                                          ^
../../dist/include/mozilla/Attributes.h:20:33: note: expanded from macro 'MOZ_INLINE'
#  define MOZ_INLINE            inline
                                ^
In file included from /var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc/mozalloc.cpp:29:
../../dist/include/mozilla/mozalloc.h:216:21: error: replacement function 'operator new[]' cannot be declared 'inline'
MOZALLOC_EXPORT_NEW MOZALLOC_INLINE
                    ^
../../dist/include/mozilla/mozalloc.h:44:27: note: expanded from macro 'MOZALLOC_INLINE'
#  define MOZALLOC_INLINE MOZ_ALWAYS_INLINE_EVEN_DEBUG
                          ^
../../dist/include/mozilla/Attributes.h:42:75: note: expanded from macro 'MOZ_ALWAYS_INLINE_EVEN_DEBUG'
#  define MOZ_ALWAYS_INLINE_EVEN_DEBUG     __attribute__((always_inline)) MOZ_INLINE
                                                                          ^
../../dist/include/mozilla/Attributes.h:20:33: note: expanded from macro 'MOZ_INLINE'
#  define MOZ_INLINE            inline
                                ^
In file included from /var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc/mozalloc.cpp:29:
../../dist/include/mozilla/mozalloc.h:222:21: error: replacement function 'operator delete' cannot be declared 'inline'
MOZALLOC_EXPORT_NEW MOZALLOC_INLINE
                    ^
../../dist/include/mozilla/mozalloc.h:44:27: note: expanded from macro 'MOZALLOC_INLINE'
#  define MOZALLOC_INLINE MOZ_ALWAYS_INLINE_EVEN_DEBUG
                          ^
../../dist/include/mozilla/Attributes.h:42:75: note: expanded from macro 'MOZ_ALWAYS_INLINE_EVEN_DEBUG'
#  define MOZ_ALWAYS_INLINE_EVEN_DEBUG     __attribute__((always_inline)) MOZ_INLINE
                                                                          ^
../../dist/include/mozilla/Attributes.h:20:33: note: expanded from macro 'MOZ_INLINE'
#  define MOZ_INLINE            inline
                                ^
In file included from /var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc/mozalloc.cpp:29:
../../dist/include/mozilla/mozalloc.h:228:21: error: replacement function 'operator delete' cannot be declared 'inline'
MOZALLOC_EXPORT_NEW MOZALLOC_INLINE
                    ^
../../dist/include/mozilla/mozalloc.h:44:27: note: expanded from macro 'MOZALLOC_INLINE'
#  define MOZALLOC_INLINE MOZ_ALWAYS_INLINE_EVEN_DEBUG
                          ^
../../dist/include/mozilla/Attributes.h:42:75: note: expanded from macro 'MOZ_ALWAYS_INLINE_EVEN_DEBUG'
#  define MOZ_ALWAYS_INLINE_EVEN_DEBUG     __attribute__((always_inline)) MOZ_INLINE
                                                                          ^
../../dist/include/mozilla/Attributes.h:20:33: note: expanded from macro 'MOZ_INLINE'
#  define MOZ_INLINE            inline
                                ^
In file included from /var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc/mozalloc.cpp:29:
../../dist/include/mozilla/mozalloc.h:234:21: error: replacement function 'operator delete[]' cannot be declared 'inline'
MOZALLOC_EXPORT_NEW MOZALLOC_INLINE
                    ^
../../dist/include/mozilla/mozalloc.h:44:27: note: expanded from macro 'MOZALLOC_INLINE'
#  define MOZALLOC_INLINE MOZ_ALWAYS_INLINE_EVEN_DEBUG
                          ^
make[5]: Leaving directory `/var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/obj-i686-pc-linux-gnu/memory/mozalloc'
make[4]: Leaving directory `/var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/obj-i686-pc-linux-gnu'
make[3]: Leaving directory `/var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/obj-i686-pc-linux-gnu'
make[2]: Leaving directory `/var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/obj-i686-pc-linux-gnu'
make[1]: Leaving directory `/var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release'
../../dist/include/mozilla/Attributes.h:42:75: note: expanded from macro 'MOZ_ALWAYS_INLINE_EVEN_DEBUG'
#  define MOZ_ALWAYS_INLINE_EVEN_DEBUG     __attribute__((always_inline)) MOZ_INLINE
                                                                          ^
../../dist/include/mozilla/Attributes.h:20:33: note: expanded from macro 'MOZ_INLINE'
#  define MOZ_INLINE            inline
                                ^
In file included from /var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc/mozalloc.cpp:29:
../../dist/include/mozilla/mozalloc.h:240:21: error: replacement function 'operator delete[]' cannot be declared 'inline'
MOZALLOC_EXPORT_NEW MOZALLOC_INLINE
                    ^
../../dist/include/mozilla/mozalloc.h:44:27: note: expanded from macro 'MOZALLOC_INLINE'
#  define MOZALLOC_INLINE MOZ_ALWAYS_INLINE_EVEN_DEBUG
                          ^
../../dist/include/mozilla/Attributes.h:42:75: note: expanded from macro 'MOZ_ALWAYS_INLINE_EVEN_DEBUG'
#  define MOZ_ALWAYS_INLINE_EVEN_DEBUG     __attribute__((always_inline)) MOZ_INLINE
                                                                          ^
../../dist/include/mozilla/Attributes.h:20:33: note: expanded from macro 'MOZ_INLINE'
#  define MOZ_INLINE            inline
                                ^
8 errors generated.
make[5]: *** [mozalloc.o] Error 1
make[4]: *** [libs_tier_base] Error 2
make[3]: *** [tier_base] Error 2
make[2]: *** [default] Error 2
make[1]: *** [realbuild] Error 2
make: *** [build] Error 2
Comment 40 cmuelle8 2013-10-27 01:43:01 UTC
Created attachment 362036 [details, diff]
/etc/portage/patches/www-client/firefox/928808_no_inline.patch

(In reply to cmuelle8 from comment #39)
> (In reply to cmuelle8 from comment #37)
> > Created attachment 361618 [details, diff] [details, diff] [details, diff]
> > firefox-24.0-r1.ebuild.patch
> 
> Latest clang from trunk has a problem with MOZINLINEs, so you might have to
> disable-replace-malloc / disable-jemalloc and comment out jemalloc export in
> the ebuild.
> 

Solvable, though still a WIP, using 
  https://bug928808.bugzilla.mozilla.org/attachment.cgi?id=820593

I'll attach it to this bug for convenience.


Currently, starting from stock portage tree, you need to put two of the attachments "as is" into

- /etc/portage/patches/www-client/firefox/928808_no_inline.patch
- /etc/portage/patches/www-client/firefox/firefox-24.0-clang-3.4svn.patch

- apply the ebuild patch to the firefox ebuild
see third attachment to this bug

- make ar, nm tools of binutils use llvm linker plugins
see bug #462554

- patch mozcoreconf-2.eclass to allow passing correct optimization flags
see bug #462488


It's not pretty and i have not set up an overlay for this, sorry.  If someone would like to include this into his/her overlay, go ahead and post to this bug.

Greetings
cmuelle8
Comment 41 moxian 2017-07-13 00:45:40 UTC
This is an old bug.

I have successfully installed (and am currently using) www-client/firefox-52.2.0 sys-devel/clang-3.9.1.

Should this bug be closed?
Comment 42 moxian 2017-07-13 03:58:38 UTC
Please ignore my comment above.
Upon closer inspection, it turns out that lto was not actually being set when building firefox.
Comment 43 Jory A. Pratt gentoo-dev 2017-08-26 17:56:22 UTC
If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system.

Thank You for your support and understanding
The Mozilla Team