For 7400, 7450, G5, -ftree-vectorize

For G5, -mcpu=G5 -mno-powerpc64 and remove the stupid kludge we are using currently for 32-bit compiles.

These options are a little risky, so let's test them thoroughly.

Actually, critical; we will ship the test beta with these.

You also may want to try GCC 4.6 - it has significant improvements in compatibility with Mac OS frameworks. Though it does not support Tiger.

GCC 4.2 could also be replaced with llvm-gcc 2.9 - it outperforms GCC 4.2 in benchmarks.

4.6 is out precisely because it doesn't support Tiger. I use Tiger myself, so that's pretty much the end of that.

Between issue 23, issue 28 and issue 50, I think we have a little too much to test in the next beta and this could introduce subtle bugs, so I'm going to defer this to the one after and mark High.

implemented for 4.0.2 in 7400, 7450 and G5

First build with G5 crashed immediately. Dropped -ftree-vectorize, replaced with -fivopts.

Absolutely no change in benchmarks. Because this is a potentially risky change with little gain, we're deferring until we have to use 4.2 and then we can see if -ftree-vectorize works again.

I researched a little bit more about the altivec related compiler flags and found out the following: Specifying an Altivec-capable CPU type does not (any longer?) automatically enable "-faltivec" (which is more or less equivalent to "-mpim-altivec") but it does just enable "-maltivec". "-faltivec" allows for access to Altivec functions without the need of a special header file while with "-maltivec" a Altivec header file is needed. "-faltivec" seems to be the old-fashioned version and Carbon (which comes from classic Mac OS) needs that type. So one always needs to pass "-faltivec" to gcc when using Carbon API calls. In any other case access to Altivec should be possible without specifying "-faltivec". But there are some other implications: when specifying a CPU type of ppc7400 together with "-faltivec" the CPU type is reverted to just ppc. That is not the case for cpu types of ppc7450 or ppc970. That behavior seems to have changed from Tiger gcc-4.0 (Apple build 5370) to the more recent versions that come with Xcode 3.

when specifying a CPU type of ppc7400 together with "-faltivec" the CPU type is reverted to just ppc.

How did you notice this?

This sounds like a bit of a minefield, so maybe we should (while gcc-4.0 is the officially supported compiler) leave the mozconfigs alone except for --enable-*strip, and make a note in the build instructions.

I changed the gcc parameters and looked at the architecture of the output file; actually I should have said "architecture" instead of "cpu type". From the manpage of gcc I get the impression that for gcc the only difference between ppc750 and ppc7400 is the switch "-maltivec". Code compiled with that switch enabled obviously can't run on G3 CPUs anymore. Hence it gets the architecture "ppc7400". That's different with "-faltivec" where gcc isolates all functions that access the vector unit so that the code itself can decide whether to use an Altivec-optimized code path or not. Hence that code gets the architecture "ppc" (but the code in that case can try to access the vector unit on a G3 CPU what will lead to an exception). For ppc7450 or ppc970 that's different because there are other optimizations apart from "-maltivec" switched on that only work with these respective CPU types - while a G5 CPU should always be able to execute code of the architecture ppc7450 as well. So switching on "-faltivec" together with cpu type of ppc7450 or ppc970 doesn't make the code runnable on G3 CPUs as well. Hence the compiled code still gets the architecture ppc7450 or ppc970.

About supported compilers: Is there really still any "support" for gcc-4.0 build 5370? For me support would be providing later gcc versions built for 10.4 that include bug fixes. Apple doesn't provide any support any more for gcc-4.0 build 5370 in Tiger. It's the same way unsupported in Tiger as later versions of gcc-4.0, gcc-4.2, llvm-gcc-4.2 or clang. Support for any compilers in Tiger is in fact up to us. There's almost no one else any more - except for Gentoo Prefix. They in fact still do support building of all those compilers, ld64 and cctools in Tiger.

Not supported by Apple -- supported by us. Since gcc-4.0(5370) is the compiler that comes with Xcode 2.5, that's the compiler I want to maintain support for out of the box. I'd like to support the linker, too, but since that won't work we'll support "yours" -- but that means we also have to distribute it, etc. I'd like to keep as many tools "standard" as possible until they don't work or can't be made to work. There are some compiler bugs in 5370, but the patches work around them.

For that reason I'm going to keep the mozconfigs otherwise the same (I did make a tweak to DEBUG which will come with the beta changesets) except for the strip options. I'm using one such strip build now on the G5 and 50.9MB is quite acceptable for size. When gcc-4.2 becomes our minimum required compiler, and I imagine it will sooner or later, then we'll revise our command line options.

Obviously gcc-4.2 will remain an option until then, but it will be experimental for now, and the required changes will be in the build notes rather than in the configs.

(changing status back to accepted since we're not moving on this yet)

Did a build with llvm-gcc-4.2 based on llvm 2.9 . The build did mainly work as well as with gcc but there were a few files which couldn't be compiled when generating debug symbols "-g" was turned on. Those files I manually compiled deleting "-g" from the command line.

Why do we build with debug symbols even the optimized builds? Shouldn't it only be activated when using the method described on the following web page? https://developer.mozilla.org/en/Building_Firefox_with_Debug_Symbols

With the resulting Aurora.app I ran dromaeo and it gave 39 runs/s on the G4 1,5 GHz vs. 53 runs/s with the same application compiled with gcc.

Did you notice that libffi isn't compiled with the compiler specified by "CC"/"CXX" but with just "usr/bin/gcc"?

We build with debug symbols on even in opt builds because we don't have a crash reporter system, and this gives me a chance to get debug information off other people's systems.

Nice spot on the libffi, although I imagine that's a Mozilla bug.

That's rather disappointing that llvm does significantly worse, but I bet people really aren't working on PPC optimization in it. IBM does and did donate quite a bit of code to gcc.

A question: on the topic of GCC 4.2. For those who have a Power Mac G5 with the dual-core PowerPC 970FX (G5) cpu, are you:

1) auto-parallelizing (-ftree-parallelize-loops)?

2) using all cores (-fopenmp or -openmp)?

Just curious.

Those are certainly ones to consider when we have to make the jump, but I have not tried them personally. Perhaps Tobias has.

As I don't have any multi-cpu Mac I can't test a build with that options. But I could very easily provide the tarball containing the gcc-4.2 installation I built. As I built it the Apple way it doesn't overwrite any files of the already installed compilers; Apple modifies the install locations of gcc components to make coexistence of various compiler versions possible. So there shouldn't be any risk in installing that tarball.

I recently built gcc-4.6 on my 10.4 installation. There weren't any problems during compilation and linking! Building pure C applications works without problems. In order to get C++ applications to be built against the (quite old) version of libstdc++ I needed to modifiy some system headers but gcc provides an easy method to do so without touching the original headers (fixincludes). Compiling Objective-C/C++ also seems to work which is needed for interfaces the Mac OS system frameworks. Compatibility with Mac OS frameworks is a new feature in gcc-4.6 and is officially supported only for 10.5 and 10.6. So finally I could get XUL compiled - but linking failed in the first attempt. There is a linker (ld64 97.17) warning for which there is already a proposed gcc fix available that I expect to appear in a future release of gcc. I applied that patch to my gcc sources built it again but didn't have the time yet to rebuild whole XUL. Just recompiling the files the linker warns about didn't help. I also noticed that in gcc-4.6 "-ftree-vectorize" is automatically switched on by "-O3" so that's expected to work in that version.

Managed to build XUL with gcc-4.6 - and it seems to work!

Found out that "ftree-vectorize" has to be turned off at least for (some?) ObjC++ files (maybe also ObjC files). Turning on "ftree-vectorize" for those files results in linker errors. So for gcc-4.6 one has to downgrade optimization level to 2. One can still manually turn on the other options O3 turns on.

For my first working XUL I compiled all ObjC++ files with O2 and all options that O3 turns on except for ftree-vectorize. All other files were built with O3. A first test of JavaScript performance gave no improvements over a gcc-4.2 compiled XUL on my 500 MHz G4 7400.

Nice! I'm not too worried about there being no performance improvement; I just didn't want there to be a significant drop. So it's good to know that the option is there if Mozilla stops supporting 4.0/4.2.

Thanks for the feedback. When you finally decide to use GCC 4.2 or 4.6, it would be interesting to see if taking advantage of parallel-processing compiler options making any difference in performance. I've read that on devices that have dual-core A9 ARM chips (like Tegra 2) and use Android OS (2.3 or higher) can do this: they use one core for the browser and other core for the Flash, for example. I wonder if this can be achieved on TenFourFox. It probably is more complicated in reality. Autovectorization is really only part of the equation: is the compiler you currently use making use of all VMX/Altivec cores on the multicore/multiprocessors on G5 macs without the use of OpenMP or the autoparallelization flags? This allow you to squeeze out the very last drop of performance.

Well THAT's impressive!

I compiled whole TenFourFox 5 (based on that first preliminar patchset) with gcc-4.6. For JavaScript and NSPR I set the optimization level to O3 (that means "tree-vectorize" on) and the rest was built with O2 and every options O3 includes except for "tree-vectorize". I chose JavaScript (including libffi) and NSPR for autovectorization because they are configured independently of the rest.

And JavaScript performance (dromaeo) on the G4 1,5 GHz improved to 59,5 runs/s. That's 10% faster! And the build was optimized for G4 7400 and not 7450 what could result in additional improvements.

Maybe autovectorization for just NSPR and JavaScript also works with gcc-4.0 ?!

Additional improvements could be achieved by using LTO but I read that for linking XUL with LTO switched on needs 8GB of RAM and my best machine has just 1.25GB.

Nice work. It might indeed. I'll schedule that for 6, though, since we're too far into 5 (I want to do only one more beta cycle, and issue 68 is higher priority).

Did one final try adding link time optimization to the gcc flags for NSPR and JavaScript. JavaScript performance in dromaeo however wasn't affected.

So now after all my tests of different toolchain versions I ended up having tarballs of gcc-4.0.1, gcc-4.2.1, gcc-4.6.0, llvm-gcc-4.2 (LLVM 2.9), clang-2.9, ld64-97.17, cctools-800, cctools-782 (needed for compatibility with LTO in gcc-4.6) ready for installation on stock Mac OS X 10.4. I wonder whether I could/should provide those packages for download in some place...

Oh that's me, Tobias, being logged in with another account.

LTO is pretty expensive anyway. The autovectorization should be the biggest win. As I say, I'm dealing with some subtleties in 5's JS I don't want to overcomplicate, but this seems a no-brainer for 6. I'll spin that off as a separate issue when 5 goes out.

All compilers and binary tool packages I built for 10.4 are now available as tarballs from the Google code project "tiger-toolchains".

Nice! However, Google might want you to put some token source up, even if it's just your patches ...

Well, I'll wait until they ask me to do so ;-).

I tried autovectorization with TFF 5.0 and gcc-4.0.1 and found out some things. GCC manpage says in the Apple versions tree-vectorize forces strict-aliasing. There is however mozilla bug 414641 concerning strict-aliasing which isn't closed yet. Because of that behaviour we cannot compile NSPR with tree-vectorize because NSPR has issues with strict-aliasing - at least turning on tree-vectorization produces warnings saying that the strict-aliasing rules are being broken. That same messages I got also for cairo, angle and growl modules. But for JavaScript it seems to be fine - at least there are no warnings. However the build isn't finished yet; I'll report if it's basically working.

I built TFF 5.0 with auto vectorization on for just JavaScript, built with gcc-4.0.1. The results in dromaeo recommended benchmarks: TFF 5.0 7450 (gcc-4.0.1) 55,66 runs/s TFF 5.0 7450 (gcc-4.0.1, auto vectorization for JS) 56,92 runs/s Aurora 5.0 7400 (gcc-4.6, auto vectorization for JS and NSPR) 59,50 runs/s

Not sure if those results are reproducible. But to me it seems for gcc-4.0.1 turning on auto vectorization isn't worth the trouble.

No, I agree, that doesn't seem worth the risk. I am planning to make some headway on methodjit for Fx7 anyway. After that, it might be worth switching compilers to get this bonus.

However, is it truly the autovectorization that makes the run faster, or is it that 4.6 makes better code?

Without autovectorization I got 55-56 runs/s on the same codebase compiled with gcc-4.2 as well as with 4.6 and now with 4.0.1. Switching on the autovectorization gave the improvement, see Comments 20 and 23. However, there seem to have been substantial changes regarding optimization in the more recent versions of gcc. And the Mac OS X support in gcc-4.6 seems to be nearly mature already (although it's the first version to support it) - at least I could build a running TenFourFox/Aurora 5 with it and it performed quite well. The main difficulty was that auto vectorization causes linker (!) failures for Objective-C/C++-code.

Some speed testing of TFF7 on a PowerBook G4 1,5 GHz running 10.4.11 set to highest performance:

TFF7.0b1 7450 (official build) : 50,3 runs/s TFF7.0b 7400 (based on Fx7.0b4): 57,3 runs/s

The custom one was compiled with gcc-4.6.1 whose "-O3" (which is what is used for most of the code) includes auto vectorization.

I attached a patch that contains the necessary patches to build with gcc 4.6. It removes the unneeded "-fpascal-strings" flag, replaces apple specific "-Oz" with "-Os", replaces apple specific "-Wmost" with "-Wall -Wno-parentheses" and adds "-mno-altivec -mabi=no-altivec" to the compiler flags for objective-c++ sources to work around a problem related to auto-vectorization.

Additionally one needs to add "-flax-vector-conversions" to both compiler commands and "-fpermissive" to the CXX command in the used mozconfig as well as delete the "-arch ..." which doesn't exist in non-apple gcc. Of course the compiler commands have to point to the gcc 4.6 respectively g++ 4.6 executables.

In the above speed test there was some Spotlight activity so I repeated the measuring.

Another speed testing of TFF7 on a PowerBook G4 1,5 GHz running 10.5.8 set to highest performance:

TFF7.0b1 7450 (official build) : 55,6 runs/s TFF7.0b 7400 (based on Fx7.0b4): 59,7 runs/s

I'm investigating moving to gcc-4.2.1 to see how far we get.

So far there have been two issues. One is that the 4.2.1 include files don't get seen by the Mozilla build system unless we forcibly add the directory, i.e., in .mozconfig,

CC="gcc-4.2 -arch ppc -I/usr/lib/gcc/powerpc-apple-darwin8/4.2.1/include" CXX="g++-4.2 -arch ppc -I/usr/lib/gcc/powerpc-apple-darwin8/4.2.1/include"

This appears to work. The other problem is that as crashes out complaining about --gdwarf2 as an illegal option while building NSPR. Tobias' gcc-4.2.1 simply symlinks /usr/libexec/gcc/powerpc-apple-darwin8/4.2.1/as to /usr/bin/as. I might write a shim as that twiddles options for it. Tobias, I'm not sure if you will want that shim in your distro.

Also, this is just to build a DEBUG build -- I haven't tried opt builds with it at all yet.

Here's the shim. This makes libffi and nsprpub happy.

And the working DEBUG4.2.mozconfig (tested only with js so far):

Well, built a full debug version of the browser in 4.2.1 and it can't stand up -- one of the scoped_ptr templates in Chromium generates incorrect code, apparently. It asserts very early in startup.

JS works great, though. Maybe we can merge the two. Or, clang.

Hmm... I built a lot of stuff using that gcc-4.2.1 including gcc-4.6 and many other stuff. I don't remember if I ever built TFF with it.

Did you untar the tarball to / in order to install it?

But with gcc-4.6 it works very well - you already tested a version of TFF built with it.

Reading my previous comments I see that I did indeed build a full release version of TFF with gcc-4.2.1 and I did not have any issues with it. Only for 4.6.1 I had to tweak it a little.

There's something wrong - maybe you need to use more recent cctools as well as this will update the assembler. I'd recommend to use cctools-800. That might solve some of the issues you encountered.

Could be that, but I would expect that if it were cctools, it might not build at all (rather than improperly), and some things do work. I'll try that when I get around to trying 4.2 again. For now 4.0.1 is still working, so we will still use that as the supported compiler. It looks like we've successfully worked around the JIT issues that Apple had with 4.0 on x86 (or maybe it was a bug in the x86 backend).

Explain the modifications you had to make for 4.6.1 (comment 19).

The later cctools will support "--gdwarf2". And I did never have to add the gcc header path manually for any project.

Building with gcc-4.2.1 worked out of the box for me - but I had recent cctools and ld64 installed in place of the ones shipped with Xcode-2.5 .

The same goes for gcc-4.6.1; I only ever used (and also built) it using recent cctools and ld64 in place of the "original" ones.

I guess you have to upgrade the whole toolchain and not just a part of it. That's definitely the way to go. Say goodbye to the Xcode-2.5 toolchain and say hello to the Xcode-3.2 toolchain - as a whole.

The modifications to gcc-4.6 header are in "/usr/lib/gcc/powerpc-apple-darwin8/4.6.1/include" (maybe also something in "/usr/lib/gcc/powerpc-apple-darwin8/4.6.1/include"). The header files that Apple shipped with gcc/g++-4.2.1 aren't compatible with gcc/g++-4.6 so there was one I had to remove completely and a couple of others I had to add or modify. Some template stuff in tere which I didn't understand completely was broken as well and I was able to fix it but it still needs passing "-fpermissive" to g++ in order to compile some stuff (some mozilla files as well).

That's probably the issue then. I think when I try this again, I'll just jump straight to 4.6.

I'd like to try a build of TFF 9.0 beta using the Xcode 3.2 toolchain. That would take me some days to complete. Would you mind uploading the current patchset?

Give me a week for that -- I'm trying to shake out random crashes from 9. I have it narrowed down to one of the VMX patches (building G5 opt with --enable-tenfourfox-g5 but NOT --enable-tenfourfox-vmx yields a stable browser, and DEBUG is also stable, so it must be a _VMX codepath that is causing trouble), so I am bisecting to narrow down the culprit(s).

Hmmm... none of those patches in their latest versions did crash 7 for me and they even worked fine in firefox 8 on linux. All in all I ran those browsers just a couple of hours. Only thing I didn't have is FirstNon8Bit().

It's probably something about 9. I have a partially VMXed build working now, with it narrowed down to one of

FirstNon8Bit() BrowserStreamParent/Child (not likely, but it appears in the backtraces) transform-vmx nsUTF8ToUnicode jpeg_consume_input nsUTF8UtilsVMX.cpp

I'm going to enable each of them one by one and see if I can ID the culprit.

BrowserStreamParent/Child, transform-vmx and jpeg_consume_input all enabled, no crashes. So that leaves us with our text translators.

I suspect it's one of those that return a length and/or pointer.

You may be partially right. nsUTF8ToUnicode is definitely a culprit; the browser goes haywire. FirstNon8Bit actually works, but all it does is scan strings, and I guess that's what makes it safe. I suspect UTF8UtilsVMX will also wreck it. It seems like whatever stuff writes to garbage collected objects is offending it.

This is all perpendicular to this bug anyway. I may ship 9 beta with them temporarily disabled until we can solve it. I think I'll try for Friday and you will get changesets then.

Might this have something to do with caching? I think of the difference between vec_st() and vec_stl(). Might those functions have to be threadsafe now?

I don't know if that's the actual problem, but I'm sure it will be in the future if it isn't already, so we should try to make sure they are threadsafe also.

Changesets are up.

Tobias, see my comment in issue 96 -- it might be time for 4.2 if your build succeeds where my 4.0.1 build is failing.

Just to not forget it: In order to build libffi with the most recent versions of ld64 one has to apply the patch from https://bugzilla.mozilla.org/show_bug.cgi?id=582690 .

I've been working on getting current WebKit to build on 10.5 PPC. From that I've learnt that when linking big files (like XUL in debug mode) you can get the error message "ld: in {some object file, framework or dynamic library}, can't map file, errno=12" which means that the linker run out of address space (which is more limited in a 32-bit environment). What the WebKit team did to get WebKit to link in 32-bit Windows is to compile groups of files (for example whole subdirectories) at once by creating all-in-one cpp files that just include all the cpp files of a group. Instead of compiling all the files of that group individually only that all-in-one file is compiled.

(By the way ;-), the results of my WebKit build work you can test here: http://code.google.com/p/leopard-webkit/ )

http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/182cfddb3ae5767e

Mozilla is forcing the issue in Fx17, so Fx18 looks like the right time to switch to gcc 4.6.

On the AuroraFox download page (http://code.google.com/p/aurorafox/downloads/list) I upload my recent mercurial patch queue which contains one patch with the changes necessary for building with gcc 4.6 (fixes_for_building_with_gcc-4.6.patch).

I tried building 4.6.3 on the G5 and it fails verification between stage 2 and stage 3. What gcc are you using, 4.6.1?

I want to install separate bintools so that 4.0.1 will still be available as a fallback strategy, and 17ESR will still be built with 4.0.1, which is why I'm dealing with this now.

Alternatively, there is 4.5.4 (Mozilla's minimum for 18 will be 4.4).

I'm using gcc 4.6.3 from macports here on 10.5 . Macports installs its own versions of ld64 and otools for building it. It will never overwrite the Apple provided versions of anything. And the paths to its bintools are hard coded into gcc's binaries, so as long as you don't touch them the toolchain will work as always.

For building on 10.4 I used the Apple version of gcc 4.2 to build gcc 4.6.1 .

Didn't you use macports to build gcc 4.6.3? In the portfile there is the following specific to 10.4: It passes the flag "--with-dwarf2" when configuring and there's a link to a corresponding mozilla bug. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248

gcc 4.6.x are the only versions that will work since Objective-C/C++ support was introduced with 4.6 .

It actually was a gcc bug not a mozilla one.

Until version 4.5 gcc didn't support the Apple Objective-C runtime library. 4.6 introduced support for it and also implemented most of Objective-C 2.0 (which isn't supported by the 10.4 Objective-C runtime library).

That's handy. I'd still like to try to build 4.6.3 myself just to ensure that it works okay in case at some point in the future MacPorts screws up 10.4 and we have to distribute a binary /opt for builders.

Well, then I suggest you take a look at the Portfile (https://trac.macports.org/browser/trunk/dports/lang/gcc46/Portfile).

gcc 4.6.3 is up and appears to work (tested it building DOSBox). I built new basic cctools to /opt/cctools-806/, and compiled /opt/gcc46/. This works.

However, it links to its own new libc. How are you getting around this to link to the system libc/libc++?

(Above you mentioned you had done so:

In order to get C++ applications to be built against the (quite old) version of libstdc++ I needed to modifiy some system headers but gcc provides an easy method to do so without touching the original headers (fixincludes).

Do you still have those?)

To make gcc build and link against the system libstdc++ you have to do what Apple does in their "build_gcc" script for gcc 4.2: Remove the subdirectory "libstdc++-v3" Configure gcc, setting the following parameters: "--with-gxx-include-dir=/usr/include/c++/4.0.0" "--with-build-sysroot=/Developer/SDKs/MacOSX10.4u.sdk" After building you have may have to modify some header files (or at least I had to do so after building using a modified Apple "build_gcc" from their gcc-4.2 sources). You'd have to compare the headers from my "gcc461-powerpc-darwin8.tar.gz" in the directories "usr/lib/gcc/powerpc-apple-darwin8/4.6.1/include" and "usr/lib/gcc/powerpc-apple-darwin8/4.6.1/include-fixed" with the corresponding ones from your build. But maybe you won't have to do so when building the default way.

BUT - as you will have to ship gcc-4.6's "libgcc_s.1.dylib" either way inside the TFF application bundle, I recommend doing the same for gcc-4.6's libstdc++.dylib . That's the way I'm doing it for the Aurora releases. You'd have to use "install_name_tool" to change the linked library paths (for that purpose there's a very simple shell script in the AuroraFox changesets).

Once again forgot to switch to my own google account...

If the configure settings don't change the need to ship the 4.6 libgcc, then I'd rather just build with 4.6's includes, unless you know this doesn't work (and then modify your post-build script for Tiger as necessary to change the executable lib paths for js and firefox).

Might be possible to avoid shipping libgcc dylib:

Read the section about "-shared-libgcc" and "-static-libgcc": https://developer.apple.com/library/mac/#documentation/DeveloperTools/gcc-4.2.1/gcc/Link-Options.html

So I understand that one can use "-static-libgcc" (while linking with gcc instead of g++) safely if everything is (or rather can be) compiled with "-fno-exceptions" or if exceptions are guaranteed to not be thrown in one and catched in another shared library.

To try that with mozilla one would have to change configure.in to set (for Darwin) MKSHLIB to the same as MKCSHLIB plus "-static-libgcc".

That would probably be preferable, but on the other hand, shipping an updated libgcc wouldn't be a bad thing ... it may actually fix some weird bugs like the atexit() problem.

FWIW, I'm using gcc 4.6.3 build in Gentoo Prefix on 10.5 - seems to work fine

We need to revert https://bugzilla.mozilla.org/show_bug.cgi?id=787931 and possibly https://bugzilla.mozilla.org/show_bug.cgi?id=784029 for 18. Mozilla will not allow gcc on OS X with Fx18, and this appears to be because the new 10.6+ widget code uses blocks. However, issue 89 will cover that.

You might want to try blocks runtime from LLVM's compiler-rt

Sounds great, except that LLVM on PPC is a mess and won't be ready for this.

(and, for that matter, the blocks code in question is regarding certain widget methods that don't even exist on 10.4, so the compiler isn't the only problem)

As for "LLVM on PPC is a mess": code of BlocksRuntime seems to be pretty portable (arch/OS/compiler independent). There's PLBlocks SDK using this code under the hood and supporting gcc 4.2 / PPC.

Got Aurora 17 built with gcc 4.7.2 . And it also seems to be working well so far. Two files needed an explicit include of unistd.h .

Comment deleted

Comment deleted

In my copious spare time, of course.

In order to build Aurora 18 with gcc 4.7 there were some more changes needed - quite some more than for gcc 4.6 .

I'm planning to stick with 4.6.3 at least for the foreseeable future, but I haven't tried making a 10.4Fx build with it yet. I will probably do so when I get the 17 beta out.

Annulen, could/would you do an Aurora 10.5 LLVM build?

What do you mean under LLVM build? If you mean clang build, it's still needs fixes to work properly on PPC.

Comment deleted

What's the point to use llvm-gcc if gcc is working? It certainly optimizes worse than gcc, especially if we take version from Xcode 3.1 (LLVM 2.6 IIRC). In LLVM trunk there were some improvements converning PowerPC, but llvm-gcc was deprecated long ago.

2012/10/23, tenfourfox@googlecode.com :

Annulen, fair enough. How are your JS skills? I ask because the AirPlay Enabler is still yet to see an inaugural release. Basically the QTE can be used as a model just remove the QuickTime bit and replace it with the AirPlay code (basically a context menu post request). Other major bottlenecks that remain are LLInt and V8. Feel free to contact me directly if any of these suit you and you need further info.

As for llvm-gcc please see comment 14.

When switching on objc-direct-dispatch in gcc 4.6 and later the linker will find the undefined symbols _objc_msgSend_Fast and maybe _objc_assign_ivar_Fast (when objc-gc is turned on). The attached piece of assembly provides those symbols. They are really just local branches to fixed addresses (in the comm page). In Apple's gcc those branch instructions directly replaced those function calls. So providing those symbols this way you get an overhead of one additional branch compared to Apple's original implementation. I also wonder if direct dispatching is really worth much (at least in 10.5 - I don't know whether it's the same in 10.4), as from what I saw by stepping through the instructions using gdb you only save a couple of instructions (inside dyld) by using direct dispatching.

There's actually a very nice way of getting the missing direct dispatch function automatically linked in. You just have to add the object file (resulting from the assembler code posted before) to the static libgcc the compiler uses. In the case of MacPorts gcc 4.7 the static libgcc is installed in "/opt/local/lib/gcc47/gcc/ppc-apple-darwin9/4.7.2/libgcc.a". Using a command similar to "ar -r -s libgcc.a objc_msgSend_Fast.o" you'll get that object file added and automatically used by gcc to satisfy the missing symbols during linking.

Well, to actually activate the faster dispatching you have to add "-fobjc-direct-dispatch" to the OS_COMPILE_CM(M)FLAGS and HOST_CM(M)FLAGS in "config/config.mk" and "js/src/config/config.mk"

Aurora 19 built with direct dispatching is stable.

I'm going to hold off on that until we see what the other builders are doing. fangism is still trucking on the Fink port and it would be nice if it could be built with the Fink gcc or the MacPorts gcc even though I will still make the gcc 4.6.3 and bintools I am using available. This way it's still a little more portable even though I agree dispatching is desirable.

After some cussing and hacking on the configure scripts, gcc 4.6.3 links and built JavaScript, and all tests pass, so I'm going to let it spin overnight and see how far it gets.

I think I'll file my suggestion in a bug to the gcc developers. Maybe they'll include it in their standard libgcc - maybe even for the next gcc4.6, if there'll be an update at all.

XPCOM does not want to build. While jsapi.h built with no comments as JS, I get

In file included from ../../dist/include/xptcall.h:21:0, from /Volumes/BruceDeuce/src/mozilla-19a/xpcom/build/../glue/nsXPTCUtils.h:8, from ../../dist/include/mozilla/XPCOM.h:177, from /Volumes/BruceDeuce/src/mozilla-19a/xpcom/build/nsXPComInit.cpp:9: ../../dist/include/jsapi.h:927:70: error: template argument 1 is invalid ../../dist/include/jsapi.h:927:72: error: expected '{' before '>' token ../../dist/include/jsapi.h:927:72: error: expected unqualified-id before '>' token In file included from ../../dist/include/jsapi.h:28:0, from ../../dist/include/xptcall.h:21, from /Volumes/BruceDeuce/src/mozilla-19a/xpcom/build/../glue/nsXPTCUtils.h:8, from ../../dist/include/mozilla/XPCOM.h:177, from /Volumes/BruceDeuce/src/mozilla-19a/xpcom/build/nsXPComInit.cpp:9: ../../dist/include/gc/Root.h: In instantiation of 'JS::Handle': ../../dist/include/jsapi.h:1386:37: instantiated from here ../../dist/include/gc/Root.h:112:7: error: invalid use of incomplete type 'class js::HandleBase' ../../dist/include/jsapi.h:927:7: error: declaration of 'class js::HandleBase'

Before I go trying to hack this and make a bigger mess, did you have to do anything? What compiler options are enabled? I have

export CC="/opt/gcc46/bin/gcc -flax-vector-conversions" export CXX="/opt/gcc46/bin/g++ -flax-vector-conversions -fpermissive" mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff-dbg mk_add_options MOZ_MAKE_FLAGS="-s -j2" mk_add_options AUTOCONF=autoconf213 etc.

I already responded by E-Mail but apparently it didn't work.

My mozconfigs look like this: export CC="/opt/local/bin/gcc-mp-4.7 -mcpu=7400 -mtune=G5" export CXX="/opt/local/bin/g++-mp-4.7 -mcpu=7400 -mtune=G5" ac_add_options --disable-tests ac_add_options --enable-optimize ac_add_options --target=powerpc-apple-darwin9 ac_add_options --enable-macos-target=10.5 ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk ac_add_options --enable-debug-symbols=-gdwarf-2 ac_add_options --with-system-jpeg ac_add_options --enable-jemalloc ac_add_options --enable-shared-js ac_add_options --enable-gstreamer

I don't need "lax-vector-conversions" anymore since I "corrected" those parts. I only have "permissive" set in the accessibility Makefile.

I had a problem with jsapi.h when I switched from gcc 4.6 to 4.7 . But as I did that switch at the same as switching to a new Aurora version I don't know whether this was because of the mozilla sources or because of the compiler switch. But it seems to be exactly your problem:

diff -r 3783afecd20a js/src/jsapi.h --- a/js/src/jsapi.h Wed Oct 10 19:52:08 2012 +0200 +++ b/js/src/jsapi.h Mon Oct 22 21:54:19 2012 +0200 @@ -916,11 +916,11 @@ * and value-extracting operations. */ template <> -class HandleBase : public ValueOperations > +class HandleBase : public ValueOperations > { - friend class ValueOperations >; + friend class ValueOperations >; const JS::Value * extract() const { - return static_cast>(this)->address(); + return static_cast>(this)->address(); } };

The original patch is included in "fixes_for_building_with_gcc-4.7.patch" in the AuroraFox changesets.

This sounds like something we should upstream. I had a feeling that was the problem.

Well, it builds and links, but it won't get off the ground:

(gdb) run Starting program: /Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS/firefox Reading symbols for shared libraries ..................................................................++ done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries .................... done

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand. 0x093091dc in .objc_class_name_CTGradient () (gdb) bt

0 0x093091dc in .objc_class_name_CTGradient ()

1 0x08234d20 in _GLOBAL__sub_I_nsCacheService.cpp () at Telemetry.h:72

2 0x8fe15670 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()

3 0x8fe0babc in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()

4 0x8fe0dcdc in __dyld__ZN11ImageLoader4linkERKNS_11LinkContextENS_15BindingLazinessENS_18InitializerRunningEj ()

5 0x8fe04070 in __dyld__ZN4dyld4linkEP11ImageLoaderNS0_15BindingLazinessENS0_18InitializerRunningE ()

6 0x8fe089cc in __dyld__Z8addImagePvPKcbbbb ()

7 0x9004b310 in NSAddImage ()

8 0x00003cbc in ReadDependentCB (aDependentLib=0xefffdfa8 "/Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS/XUL", do_preload=) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/glue/standalone/nsGlueLinkingOSX.cpp:142

9 0x00003a2c in XPCOMGlueLoadDependentLibs (xpcomDir=0xefffe808 "/Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS", cb=0x3c74 ) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/glue/standalone/nsXPCOMGlue.cpp:106

10 0x00003f78 in XPCOMGlueLoad (xpcomFile=0xeffff128 "/Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS/libxpcom.dylib", func=0xefffec68) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/glue/standalone/nsGlueLinkingOSX.cpp:181

11 0x000038f0 in XPCOMGlueStartup (xpcomFile=) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/glue/standalone/nsXPCOMGlue.cpp:45

12 0x00004c9c in main (argc=1, argv=0xeffff62c) at /Volumes/BruceDeuce/src/mozilla-19a/browser/app/nsBrowserApp.cpp:232

(gdb)

This is, you will recall, issue 169 where it crashes on termination, so the _CTGradient is a red herring. It looks like for some reason it can't load its dylibs, even though it has the right path to XUL and libxpcom.dylib. I'm going to fiddle with this some more unless this looks familiar.

This is lower level. TestXPTCInvoke isn't working either, and also crashes in dyld (and it just links against libxpcom):

Starting program: /Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/xpcom/reflect/xptcall/tests/TestXPTCInvoke Reading symbols for shared libraries ....................................................................+++.....+++...................warning: .o file "/Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/toolkit/library/../../xpcom/reflect/xptcall/src/md/unix/xptcstubs_asm_ppc_darwin.o" more recent than executable timestamp .+ done

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand. 0x093091dc in .objc_class_name_CTGradient () (gdb) bt

0 0x093091dc in .objc_class_name_CTGradient ()

1 0x08234d20 in _GLOBAL__sub_I_nsCacheService.cpp () at Telemetry.h:72

2 0x8fe15670 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()

3 0x8fe0babc in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()

4 0x8fe0ba4c in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()

5 0x8fe0ba4c in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()

6 0x8fe0d604 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()

7 0x8fe02cb4 in __dyld__ZN4dyld24initializeMainExecutableEv ()

8 0x00001cfc in _start ()

9 0x00001bc8 in start ()

So if I can get this working, I can probably get the browser up.

The only difference between js, which links and runs fine, and TestXPTCInvoke, which does not, is that js links /usr/lib/libobjc.A.dylib while TXI links /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa and libxpcom. Neither do any screwing around with libraries.

It's certainly possible it could be the ObjC runtime, but if so, I don't understand why js works because theoretically both are ultimately linking back to the 10.4 libobjc. Given that it gets out of dyld into something looking like Mozilla (nsCacheService, which would indeed load very early), it probably isn't dyld actually.

When I built TenFourFox with gcc 4.6 I didn't have any problems like this. So I'd suspect that the efforts to speed up the application launch are incompatible with Tiger dyld.

I'm going to try installing the MacPorts 4.6.3 and see if that has the issue fixed. It's certainly possible I did something wrong making gcc. If that doesn't help either, then 10.4 might have to limp along with 4.0.1.

MacPorts gcc-mp-4.6 also fails with the exact same problem. It looks like it cannot be used to build Firefox on 10.4.

If anyone has any suggestions from the floor, go right ahead, or we'll just wontfix this and see how far we get with 4.0.1. (I would imagine not a lot farther, given the hacking needed for 17.)

Changesets for 19 and gcc 4.6.3. Beer if anyone gets it to work on 10.4. Use the MacPorts gcc 4.6.3. The changesets are very rough, and are just to get things compiled.

Wrong folder. This is the correct set of changesets.

Looks like annulen pointed this out way back in comment 2, so it may simply be a known problem they do not intend to fix.

Cannot you just build it on 10.5 with -mmacosx-min-version=10.4?

2012/12/6, tenfourfox@googlecode.com :

Reading the comments, I had managed to build TFF 5 and 7 successfully using gcc 4.6 on 10.4. I even sent you a working copy by E-Mail if I remember correctly. So it's definitely possible. Did you use ld64-97.17 for linking everything?

Apart from that you should definitely prefer gcc 4.2.1 . You can get it from here: http://r.research.att.com/tools/ .

You should also try launching the same binary on 10.5 or 10.6 . That way you'd know whether the problem is in the OS (dylib, libobjc, ...) or the mozilla code.

annulen, I don't have any 10.5 systems anymore. My Intel mini I use for Android work is 10.6, and everything else is 10.4.

% gcc-mp-4.6 -print-prog-name=ld /opt/local/bin/ld % /opt/local/bin/ld -v @(#)PROGRAM:ld PROJECT:ld64-97.17

For that matter, the regular gcc 4.0.1 links with 97.17 also (in fact, it won't link otherwise).

I just finished building 4.4. Why 4.2.1 over 4.4? I haven't tried making anything with it yet.

As far as I know the OS X ObjC runtime is supported since 4.6 .

10.6 with Rosetta should suffice for testing or won't it?

I can test on 10.5 PPC if somebody builds binary. I can compile too, but it probably would take much more time to set everything up.

2012/12/6, tenfourfox@googlecode.com :

I'm going to build that using my own old gcc 4.6.1 that uses system libstdc++ instead of gcc's own.

Well, it should be possible to ship any libstdc++ dylib within 10.4Fx bundle.

2012/12/6, tenfourfox@googlecode.com :

Yes, that's how AuroraFox is shipped. But maybe xpcom/dyld can't deal with that on 10.4 .

gcc 4.4 does not trigger this issue with dyld. It's having trouble with the ObjC runtime, however, so Tobias may be right about trying 4.2-apple. TestXPTCInvoke runs fine, but the browser crashes early in startup after the libraries load, somewhere in Chromium IPC. This might be solveable.

I think it's miscompiling the ObjC in the autorelease pool code, and I don't know how to solve this. Tobias, I don't think you ever played with 4.4, did you?

Next attempt will be 4.2, I guess, using the Apple gcc 4.2 code from the link above.

I did never try using 4.4 as I read early about it not supporting (well enough) the OS X Objective-C runtime. Maybe gcc 4.7 would be worth a try... I never tried that on 10.4 though.

Well, it certainly looks like it doesn't. It had a lot of trouble with stuff gcc 4.0.1 had no objection to. So it's 4.2, next. Given the problems with 4.6 I don't think 4.7 will be better unless you know something different.

Did not work either using my gcc 4.6.1 . Did a debug build without optimization (JS now works with -O0). Here the backtrace:

0 0x07f44ea0 in ?? ()

1 0x083728dc in atexit_common (r=0xefffe2c8, dso=0x8371000) at /Volumes/Mac_OS_9/gcc-4.6.0/build/obj/src/gcc/config/darwin-crt3.c:155

2 0x08372ee8 in __cxa_atexit (func=, arg=,

dso=<value temporarily unavailable, due to optimizations>) at /Volumes/Mac_OS_9/gcc-4.6.0/build/obj/src/gcc/config/darwin-crt3.c:155

3 0x08374c64 in __static_initialization_and_destruction_0 () at new:93

4 0x08374ce8 in _GLOBAL__sub_I_nsCacheService.cpp () at new:93

5 0x8fe14d68 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()

6 0x8fe0b7bc in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()

7 0x8fe0d950 in __dyld__ZN11ImageLoader4linkERKNS_11LinkContextENS_15BindingLazinessENS_18InitializerRunningEj ()

8 0x8fe03f6c in __dyld__ZN4dyld4linkEP11ImageLoaderNS0_15BindingLazinessENS0_18InitializerRunningE ()

9 0x8fe086cc in __dyld__Z8addImagePvPKcbbbb ()

10 0x9004c650 in NSAddImage ()

11 0x000090cc in ReadDependentCB (aDependentLib=0xefffe6f0 "/Volumes/Mac_OS_9/tenfourfox/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS/XUL", do_preload=false)

at /Volumes/Mac_OS_9/tenfourfox/xpcom/glue/standalone/nsGlueLinkingOSX.cpp:142

12 0x00006eb4 in XPCOMGlueLoadDependentLibs (xpcomDir=0xefffef60 "/Volumes/Mac_OS_9/tenfourfox/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS",

cb=0x908c <ReadDependentCB>) at /Volumes/Mac_OS_9/tenfourfox/xpcom/glue/standalone/nsXPCOMGlue.cpp:106

13 0x00009264 in XPCOMGlueLoad (xpcomFile=0xeffff4c4 "/Volumes/Mac_OS_9/tenfourfox/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS/libxpcom.dylib",

func=0xeffff3bc) at /Volumes/Mac_OS_9/tenfourfox/xpcom/glue/standalone/nsGlueLinkingOSX.cpp:181

14 0x00006cc8 in XPCOMGlueStartup (xpcomFile=0xeffff4c4 "/Volumes/Mac_OS_9/tenfourfox/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS/libxpcom.dylib")

at /Volumes/Mac_OS_9/tenfourfox/xpcom/glue/standalone/nsXPCOMGlue.cpp:45

15 0x00003df0 in main (argc=1, argv=0xeffff9bc) at /Volumes/Mac_OS_9/tenfourfox/browser/app/nsBrowserApp.cpp:232

darwin-crt3.c wasn't changed at least since gcc 4.2, so the problem shouldn't be in there. So the most likely cause is indeed dyld. And the fact that the same compiler could build a working TenFourFox 7 leads to the conclusion that some change in the mozilla code base (I don't think TenFourFox patches play into that, or might they) triggers that crash - but only when built with gcc 4.6, optimization isn't the cause either as it was switched off in my build.

I'm not hooked into anything that loads libraries, no.

I'm going to undo the hacking I did to the ObjC for 4.4 and then try Apple gcc 4.2. That's better than nothing.

Tried my build in 10.5 - and it crashes at the same point but with a better backtrace:

0 0x07f44ea0 in ?? ()

1 0x083728dc in atexit_common (r=0xefffe1a8, dso=0x8371000) at /Volumes/Mac_OS_9/gcc-4.6.0/build/obj/src/gcc/config/darwin-crt3.c:256

2 0x08372ee8 in __cxa_atexit (func=, arg=, dso=) at /Volumes/Mac_OS_9/gcc-4.6.0/build/obj/src/gcc/config/darwin-crt3.c:514

3 0x08374c64 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /Volumes/Mac_OS_9/tenfourfox/netwerk/cache/nsCacheService.cpp:1073

4 0x08374ce8 in _GLOBAL__sub_I_nsCacheService.cpp () at /Volumes/Mac_OS_9/tenfourfox/netwerk/cache/nsCacheService.cpp:3037

5 0x8fe13834 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE ()

6 0x8fe0f248 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()

7 0x8fe0f36c in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()

8 0x8fe0b4ec in __dyld__Z8addImagePvPKcbbbb ()

9 0x976c0c08 in NSAddImage ()

10 0x000090cc in ReadDependentCB (aDependentLib=0xefffe550 "/Volumes/Mac_OS_9/tenfourfox/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS/XUL", do_preload=false) at /Volumes/Mac_OS_9/tenfourfox/xpcom/glue/standalone/nsGlueLinkingOSX.cpp:142

11 0x00006eb4 in XPCOMGlueLoadDependentLibs (xpcomDir=0xefffedc0 "/Volumes/Mac_OS_9/tenfourfox/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS", cb=0x908c ) at /Volumes/Mac_OS_9/tenfourfox/xpcom/glue/standalone/nsXPCOMGlue.cpp:106

12 0x00009264 in XPCOMGlueLoad (xpcomFile=0xeffff324 "/Volumes/Mac_OS_9/tenfourfox/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS/libxpcom.dylib", func=0xeffff21c) at /Volumes/Mac_OS_9/tenfourfox/xpcom/glue/standalone/nsGlueLinkingOSX.cpp:181

13 0x00006cc8 in XPCOMGlueStartup (xpcomFile=0xeffff324 "/Volumes/Mac_OS_9/tenfourfox/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS/libxpcom.dylib") at /Volumes/Mac_OS_9/tenfourfox/xpcom/glue/standalone/nsXPCOMGlue.cpp:45

14 0x00003df0 in main (argc=1, argv=0xeffff80c) at /Volumes/Mac_OS_9/tenfourfox/browser/app/nsBrowserApp.cpp:232

The fact that it crashes on 10.5 as well makes me assume that chances are that it'd work when built with gcc 4.7 !

Why would it crash in 10.5? If it's just dyld, it should "just work," I would think. But clearly it's the same backtrace.

Incidentally, the link is dead to the Apple gcc on that page, but fortunately I'd already grabbed a copy some time ago. I'll host it here if it works.

If you run an otool -hlL on the 4.0- and 4.6-built libxpcom.dylib's, are there any substantial differences? How about otool -TR?

Unfortunately I already torched my 4.6 build, so I can't comp them. Tobias?

The AT&T gcc 4.2 is not suitable for Tiger; it uses system as, which we already know didn't work as is from my previous 4.2 failure. MacPorts apple-gcc42 does include updated cctools, along with ld 97.17, so that's what we'll standardize on. js does pass all tests after a bit of tweaking for gcc PR39608, so I'll leave it to build the rest overnight.

Here the output of otool -hlL of TenFourFox 17 (gcc 4.0, targetting 10.4), TenFourFox 19 (gcc 4.6, targetting 10.4) and Aurora 19 (gcc 4.7, targetting 10.5). I ran otool against XUL because libxpcom can obviously be loaded correctly but libxpcom fails upon loading XUL. I also tried replacing the 4.6 built XUL with the 4.7 built one and it loads on 10.5 (it crashes later on after opening the first window but that's no surprise). Replacing the 4.6 built XUL with the one from TenFourFox 17 results in an error message that 17.0.1 is not compatible with 19.0a2 which should indicate that it did load XUL and successfully requested it's version number.

A three way comparison: The 4.6 built XUL contains an additional section __image_info containing a segment __OBJC which also exists in the 4.7 built one. It does also contain an additional section __static_data containing a segment __DATA which also exists in the 4.7 built one but with different alignment. Instead of one section __bss the 4.6 built one has __bss0, __bss1, __bss2, __bss3, __pu_bss2 and __pu_bss3, all of them containing one segment __DATA. The 4.7 built one ... . gcc 4.6 built the section __gcc_except_tab with an alignment of 1 instead of an alginment of 4 built by 4.0. The 4.7 built one doesn't have this section at all, but the exception settings are also different. The segment __TEXT in section __text has slightly different (less) flags set when built with 4.6 and in section __eh_frame the segment __TEXT has some flags set opposed to no flags set when built with 4.0. 4.7 produced the same flags as 4.0 but aligned the section to 32 instead of 16, and 4.7 didn't produce any __eh_frame section at all.

The output of otool -TR doesn't seem to be comparable but here the output of it run against the 4.6 built XUL.

A try to build with 4.7 seems to be worth it. I'll do it from 10.5 targetting 10.4 like annulen suggested.

There was one fact missing in the comparison: gcc 4.7 produced __bss and _pu_bss sections like 4.6 but one more of each.

There was (until now) one obstacle when targetting another OS version. Thy python virtual environment which is used for building chromium ipc overrides the deployment target version with the one that Python was originally built with. That was because of a Python bug that should be solved in later versions of Python 2.7 . Though I couldn't find out from which exact version on this bug is fixed. I removed the part dealing with that from build/virtualenv/populate_virtualenv.py .

MacPorts apple-gcc42 crashes in the same way!

I think we're dead.

Starting program: /Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS/firefox Reading symbols for shared libraries .................................................................+ done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries ................... done

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand. 0x04115510 in ?? () (gdb) bt

0 0x04115510 in ?? ()

1 0x052f1d80 in atexit_common (r=0xefffda68, dso=0x52f0000) at /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_apple-gcc42/apple-gcc42/work/objroot/src/gcc/config/darwin-crt3.c:261

2 0x052f2378 in __cxa_atexit (func=, arg=, dso=) at /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_apple-gcc42/apple-gcc42/work/objroot/src/gcc/config/darwin-crt3.c:519

3 0x052f2528 in __static_initialization_and_destruction_0 (__initialize_p=, __priority=) at /Volumes/BruceDeuce/src/mozilla-19a/netwerk/cache/nsCacheService.cpp:1073

4 0x8fe15670 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()

5 0x8fe0babc in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()

6 0x8fe0dcdc in __dyld__ZN11ImageLoader4linkERKNS_11LinkContextENS_15BindingLazinessENS_18InitializerRunningEj ()

7 0x8fe04070 in __dyld__ZN4dyld4linkEP11ImageLoaderNS0_15BindingLazinessENS0_18InitializerRunningE ()

8 0x8fe089cc in __dyld__Z8addImagePvPKcbbbb ()

9 0x9004b310 in NSAddImage ()

10 0x000046d0 in _ZL15ReadDependentCBPKcb (aDependentLib=0xefffe2b8 "/Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS/XUL", do_preload=) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/glue/standalone/nsGlueLinkingOSX.cpp:142

11 0x0000423c in XPCOMGlueLoadDependentLibs (xpcomDir=0xefffe738 "/Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS", cb=0x4510 <_ZL15ReadDependentCBPKcb>) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/glue/standalone/nsXPCOMGlue.cpp:106

12 0x000043f0 in XPCOMGlueLoad (xpcomFile=0xefffec9c "/Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS/libxpcom.dylib", func=0xefffeb98) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/glue/standalone/nsGlueLinkingOSX.cpp:181

13 0x000042f0 in XPCOMGlueStartup (xpcomFile=) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/glue/standalone/nsXPCOMGlue.cpp:45

14 0x00003898 in main (argc=1, argv=0xeffff5c4) at /Volumes/BruceDeuce/src/mozilla-19a/browser/app/nsBrowserApp.cpp:232

(gdb)

What worries me here is this strongly suggests Mozilla changed something about how 19 is built in such a way it can no longer be loaded. Given what I had to do to DOM bindings to get their SFINAE templates to build under 4.2.1, I don't even know if I can get it to compile with 4.0.1, and even then now I'm really concerned it wouldn't even work anyway.

On the off chance, I'm going to rebuild it without the -mabi=... for ObjC, since this is an Apple compiler and should not need it. If it still doesn't work, then I'm totally out of ideas.

Obviously the gcc 4.7 built XUL crashes, too.

No difference. Time to start comparing changelists. I'm assuming this was something landed for 19, though I don't know.

I relinked XUL manually forcing it to link targetting 10.5 (that affects dyld glue code and libraries). The product crashes in the same way. So it's not the linker but must be something in the compiled code. After manually stripping (strip -Sx, ld -dead_strip) XUL it crashes at a differet point but still during __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE.

Maybe dynamic-no-pic woud make a difference?

I'll now try and see if current Aurora 19 still works on 10.5...

I'm still thinking this has to do with the ObjC runtime somehow. The only compiler that "worked" (i.e., didn't crash after dyld loaded XUL) was gcc 4.4, which we know has defective ObjC support. I wonder if Mozilla changed something to require runtime 2.0, which would be a showstopper on Tiger (but then I'd think we could shim it with gcc's libobjc, right?).

I don't think dynamic-no-pic is the problem; the debug builds have never been built with it before. Worth a try if nothing else jumps out.

Regarding the ObjC runtime: In the gcc 4.6/4.7 man page (see section about "-fobjc-abi-version") and the gcc sources you see that ObjC runtime 2.0 is 64 bit exclusively and that from 10.5 on the 32 bit runtime was extended with the most important extensions of ObjC 2.0 (FSF gcc lacks some of those, at least in ObjC++). So the switch "-fobjc-abi-version" needs a value of 0 for 10.4, a value of 1 for 32 bit on 10.5 and later (0 does also work but you won't get the ObjC 2.0 extensions) and 2 only for 64 bit.

So, provided it still works on 32 bit 10.5, ObjC 2.0 runtime isn't required. I currently build with fobjc-abi-version set to 1 and provided the description in the man page is correct the default would be 0 even on 10.5 . I already built 19 without explicitly setting fobjc-abi-version and it worked.

Ok, this is weird: according to the otool dumps from Tobias, XUL built by 4.6 and 4.7 is linked to two different copies of libgcc_s.dylib! Quoting from XUL_hlL.zip/46XUL_hlL:

"Load command 37 cmd LC_LOAD_DYLIB cmdsize 52 name /usr/lib/libgcc_s.1.dylib (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 1.0.0 compatibility version 1.0.0 Load command 38 cmd LC_LOAD_DYLIB cmdsize 84 name /usr/lib/gcc/powerpc-apple-darwin8/4.6.1/libgcc_s.1.dylib (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 1.0.0 compatibility version 1.0.0"

This almost certainly doesn't work -- and since AFAIK darwin-crt3.o is part of libgcc, I bet it's what's causing the crash.

Now, the question is why is gcc doing this and how do we get it to stop?

That's correct and the way recent versions of gcc link every binary on OS X. Even the compiler itself is linked that way. It links to system libgcc first so that only in case the system provided libgcc doesn't contain the needed symbol it is looked up in the compiler's libgcc. I read some discussion about that in the gcc bugtracker and/or mailing list.

Btw source code for darwin-crt3 wasn't changed at least since gcc 4.2 . I didn't check 4.0 yet.

By the way, since it's crashing with EXC_BAD_INSTRUCTION: what is the bad instruction?

I'd guess it branches to a wrong address.

Well, according to the backtraces it's the call to _keymgr_get_and_lock_processwide_ptr that fails. That function is part of /usr/lib/libSystem.B.dylib .

darwin-crt3 definitely needs some maintenance. On our platform it chooses the ppc code path but in fact that code path is for the special case of 10.3.9 PPC only. I think we should change that. Some more strangeness: it calls _keymgr_get_and_lock_processwide_ptr and after that loads the library that contains that symbol (libSystem.B.dylib). Well, after all it used to work that way. But you see something? The whole thing is ifdefed with PIC which suggest that the code is needed for PIC only - and will probably not be used with dynamic-no-pic.

I think building with dynamic-no-pic should definitely be tried.

And maybe we should get rid of the hacks that make binaries built on 10.4 work on 10.3.9 as well. There should be two versions of darwin-crt3: a special one that will only be used when --macosx-version-min is set to 10.3.9 and another standard one that doesn't make any differences between CPU architectures.

Aurora 19 still working when built with gcc 4.7 mdynamic-no-pic (untested with PIC).

Targetting 10.5 obviously

Okay, that makes sense. I spent the day building a Raspberry Pi laptop, so now I'll spend the night rebuilding. :)

Same error, same stack (4.6.3).

I'm going to lock myself in my office and go through all the changesets when I get back from rescuing a 6100 tomorrow.

Well, might still be unrelated to the mozilla source but something gcc does differently when targetting 10.4 . Maybe I should rebuild with mmacosx-version-min set to 10.4, fobjc-abi-version set to 0 but the SDK set to 10.5 . But there are also the exception settings that have been modified in the TenFourFox changesets but which I left untouched for AuroraFox.

... but TenFourFox 7 could be built correctly with gcc 4.6.1 what now fails.

There's one thing I don't understand about your theory. Does gcc recompile gcc/config/darwin-crt*.c after it's built? If not, I think I might need to rebuild the compiler with modifications.

How did you discover it was _keymgr_get_and_lock_processwide_ptr ?

I'm rebuilding MacPorts gcc at the moment. I completely removed darwin-crt2 since that seems to be needed for 10.3 compatibility exclusively and the Intel version doesn't compile it. From darwin-crt3 I removed all the "#ifdef ppc" parts leaving their else parts since also that seems to be there for 10.3 compatibility only.

It's _keymgr_get_and_lock_processwide_ptr because of the line numbers in the backtrace. Line 519 and 514 are both the call to that function.

Lines 261 btw. 256 in fact.

Finally found something that may bring us one step further! The modified darwin-crts didn't change anything; Now the function call to __keymgr_get_and_lock_processwide_ptr_2 crashes. Regarding the darwin-crts: gcc only links crt2 into the binary when macosx-version-min is set to 10.3 or earlier, and crt3 only when targetting 10.4 or earlier. But you can avoid the (crashing) call to cxa_exit by setting fno-use-cxa-atexit when compiling. I recompiled nsCacheService (using gcc 4.6.3) with that switch set and after that the crash happens in another static variable initialization from another source file. Now I would expect gcc to generate a call to atexit instead of ___cxa_atexit (which crt3 would catch as well) like the gcc man page says but in fact the call to atexit is completely omitted. I'd expect that to bring some more problems but we might get somewhat further. Btw no-use-cxa-atexit was default in the 10.4 system compiler but later XCode versions of gcc (since 2,3 I think) changed that to be on by default.

Out of curiosity I relinked the crashing XUL once more with mmacosx-version-min set to 10.5 and in the backtrace the crash happens directly in something called by __static_initialization_and_destruction_0, almost surely ___cxa_atexit. So that means that the fault is in the compiled code - but that may also come from a system header.

Interesting. This might even improve issue 169.

I'm seriously considering making a build of 17, which is known to work, with gcc 4.6.3 so that we totally rule out the compiler as a cause. But trying -fno-use-cxa-atexit on 19 first seems easy enough.

You know, speaking of, we didn't start having troubles with the C++ runtime until issue 169 ...

This is what I found to be most related to our problem: http://www.cocoabuilder.com/archive/xcode/250486-xcode-2-3-breaks-bundle-static-object-destruction-fuse-cxa-atexit-help.html That seems to be issue 169 , considering that XUL is loaded more like a bundle than a dylib (neither the firefox binary nor libxpcom link directly to it).

The fact that when compiling for 10.5 I don't get any difficulties makes me think that the problematic piece must be either in the system headers or in some mozilla headers that are different (by means of #ifdefs and/or the TenFourFox changesets) when compiling for 10.4 . For example nsCacheService includes NSPR headers and the resulting object does a direct call to OSAtomicAdd32. Maybe the cause for the crash is the half rotten state of NSPR after all...

Hmm. The 10.4 headers do not like being compiled with -fno-use-cxa-atexit:

gmake[5]: * [bignum.o] Error 1 gmake[5]: * Waiting for unfinished jobs.... In file included from ../dist/system_wrappers/sys/wait.h:3:0, from /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdlib.h:64, from ../dist/system_wrappers/stdlib.h:3, from /Volumes/BruceDeuce/src/mozilla-19a/mfbt/double-conversion/utils.h:31, from /Volumes/BruceDeuce/src/mozilla-19a/mfbt/double-conversion/bignum-dtoa.h:31, from /Volumes/BruceDeuce/src/mozilla-19a/mfbt/double-conversion/bignum-dtoa.cc:30: /Developer/SDKs/MacOSX10.4u.sdk/usr/include/sys/wait.h:84:24: error: multiple types in one declaration In file included from ../dist/system_wrappers/stdlib.h:3:0, from /Volumes/BruceDeuce/src/mozilla-19a/mfbt/double-conversion/utils.h:31, from /Volumes/BruceDeuce/src/mozilla-19a/mfbt/double-conversion/bignum-dtoa.h:31, from /Volumes/BruceDeuce/src/mozilla-19a/mfbt/double-conversion/bignum-dtoa.cc:30: /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdlib.h:256:25: error: multiple types in one declaration

I'm going to mess with this a little.

... but it DOESN'T happen with Apple gcc 4.2.1. So we'll leave that to build overnight and see how far we get.

The offending lines were innocent typedefs. I don't know what to make of that, but I suspect they weren't really the problem.

Crash, but this time in nsCOMPtr. That doesn't sound any better.

I couldn't find anything obvious in the changesets, by the way.

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand. 0x041123d0 in ?? () (gdb) bt

0 0x041123d0 in ?? ()

1 0x052f3374 in __static_initialization_and_destruction_0 (__initialize_p=, __priority=) at nsCOMPtr.h:471

2 0x8fe15670 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()

3 0x8fe0babc in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()

4 0x8fe0dcdc in __dyld__ZN11ImageLoader4linkERKNS_11LinkContextENS_15BindingLazinessENS_18InitializerRunningEj ()

5 0x8fe04070 in __dyld__ZN4dyld4linkEP11ImageLoaderNS0_15BindingLazinessENS0_18InitializerRunningE ()

6 0x8fe089cc in __dyld__Z8addImagePvPKcbbbb ()

7 0x9004b310 in NSAddImage ()

8 0x000046d0 in _ZL15ReadDependentCBPKcb (aDependentLib=0xefffe338 "/Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS/XUL", do_preload=) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/glue/standalone/nsGlueLinkingOSX.cpp:142

9 0x0000423c in XPCOMGlueLoadDependentLibs (xpcomDir=0xefffe7b8 "/Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS", cb=0x4510 <_ZL15ReadDependentCBPKcb>) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/glue/standalone/nsXPCOMGlue.cpp:106

10 0x000043f0 in XPCOMGlueLoad (xpcomFile=0xefffed1c "/Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS/libxpcom.dylib", func=0xefffec18) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/glue/standalone/nsGlueLinkingOSX.cpp:181

11 0x000042f0 in XPCOMGlueStartup (xpcomFile=) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/glue/standalone/nsXPCOMGlue.cpp:45

12 0x00003898 in main (argc=1, argv=0xeffff634) at /Volumes/BruceDeuce/src/mozilla-19a/browser/app/nsBrowserApp.cpp:232

This explains the multiple types problem. I'll work on this between meetings today.

bruce:/home/spectre/src/bruce/mozilla-19a/% grep -r pid_t * | grep define configure:#define pid_t int ipc/chromium/src/third_party/libevent/configure:#define pid_t int js/src/configure:#define pid_t int nsprpub/pr/src/md/unix/uxproces.c:#define PID_HASH_MASK ((pid_t) (NBUCKETS - 1)) ... bruce:/home/spectre/src/bruce/mozilla-19a/% grep -r mode_t * | grep define configure:#define mode_t int ... js/src/configure:#define mode_t int ... nsprpub/pr/tests/socket.c:#define mode_t int nsprpub/pr/tests/testfile.c:#define mode_t int nsprpub/pr/tests/thrpool_client.c:#define mode_t int nsprpub/pr/tests/thrpool_server.c:#define mode_t int nsprpub/pr/tests/udpsrv.c:#define mode_t int

That pid_t mode_t thing appears to be a configure/autoconf problem. I'm quite sure this happens when you pass fno-use-cxa-atexit to gcc when compiling C/ObjC code which will return -1 and the configure script will take this as a no for all tests. Recent versions of gcc don't accept C++/ObjC++ flags when compiling C code and vice versa.

It wasn't in the CC string, but it must have been a glitch, because when I reran it to generate confdefs.h it suddenly "just worked." It's building with 4.6.3 now again, but with -mmacosx-version-min=10.4 and -fno-use-cxa-atexit.

So that cxa-atexit thing doesn't seem to be the root cause for our problems. But I found something more, a leftover in gcc from the days of the old 32 bit linker. Stepping in the debugger through the calls that lead to the crash reveals that the incorrect branches are being done by so called branch islands that gcc compiles into the object files in order to not always issue expensive long branches, even when they aren't necessary. Gcc defaults to generate those stub islands with mmacosx-version-min set to 10.4 or earlier, and doesn't do it for 10.5 and later. This behaviour was introduced into gcc svn trunk at revision 162299, that was after the release of gcc 4.4.4 and gcc 4.5.0 . Before that FSF gcc defaulted to not generate those stub islands what explains why the build with gcc 4.4 didn't have that problem. Now those stub islands aren't really OS dependent but depend on the capability of the linker to replace the long calls with short calls where possible. You see those stub islands by searching the dylib (XUL for example) for symbols that contain "island" in their names. TFF 17 and Aurora doesn't have any of those symbols in their XUL libraries while our TFF 19 builds all do have them. Now that we know that the stub islands generated by gcc (even Apple's gcc) don't always behave correct, we have to switch them off by simply specifying -mlongcall when building with mmacosx-version-min set to 10.4 (the linker sets its own macosx-version-min switch automatically based on the value of the environment variable MACOSX_DEPLOYMENT_TARGET, defaulting to the current OS version I assume). Now again everything needs to be rebuilt to make sure all branch island are gone in the resulting binary, but this time I've got higher hopes that this will make it work again.

-mlongcall sounds like a plausible factor, but trying to build JS with it causes gcc 4.6.3 to die with an internal compiler error (!). Adding -mdynamic-no-pic -read_only_relocs suppress just makes it die later in the JS build. I'm trying it with 4.2.1 right now and so far it's getting through it.

Does the gcc47 port work on darwin8? I see you did some work with it: https://trac.macports.org/ticket/34385

(btw, no joy with -mmacosx-version-min=10.4 and -fno-use-cxa-atexit but you knew that already)

Again with the crashing. Though the stack is a little more prosaic:

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand. 0x07319070 in ?? () (gdb) bt

0 0x07319070 in ?? ()

1 0x07e80530 in atexit_common (r=0xefffda28, dso=0x7e7f000) at /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_apple-gcc42/apple-gcc42/work/objroot/src/gcc/config/darwin-crt3.c:261

2 0x07e80b28 in __cxa_atexit (func=, arg=, dso=) at /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_apple-gcc42/apple-gcc42/work/objroot/src/gcc/config/darwin-crt3.c:519

3 0x07e80cc0 in __static_initialization_and_destruction_0 (__initialize_p=, __priority=) at /Volumes/BruceDeuce/src/mozilla-19a/netwerk/cache/nsCacheService.cpp:1073

4 0x07e80d34 in global constructors keyed to _ZN26nsCacheProfilePrefObserver6AddRefEv () at /Volumes/BruceDeuce/src/mozilla-19a/netwerk/cache/nsCacheService.cpp:3038

5 0x8fe15670 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()

6 0x8fe0babc in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()

7 0x8fe0dcdc in __dyld__ZN11ImageLoader4linkERKNS_11LinkContextENS_15BindingLazinessENS_18InitializerRunningEj ()

8 0x8fe04070 in __dyld__ZN4dyld4linkEP11ImageLoaderNS0_15BindingLazinessENS0_18InitializerRunningE ()

9 0x8fe089cc in __dyld__Z8addImagePvPKcbbbb ()

10 0x9004b310 in NSAddImage ()

11 0x00004620 in _ZL15ReadDependentCBPKcb (aDependentLib=0xefffe2c8 "/Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS/XUL", do_preload=) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/glue/standalone/nsGlueLinkingOSX.cpp:142

12 0x0000405c in XPCOMGlueLoadDependentLibs (xpcomDir=0xefffe738 "/Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS", cb=0x4460 <_ZL15ReadDependentCBPKcb>) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/glue/standalone/nsXPCOMGlue.cpp:106

13 0x00004280 in XPCOMGlueLoad (xpcomFile=0xefffec9c "/Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS/libxpcom.dylib", func=0xefffeb98) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/glue/standalone/nsGlueLinkingOSX.cpp:181

14 0x00004160 in XPCOMGlueStartup (xpcomFile=) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/glue/standalone/nsXPCOMGlue.cpp:45

15 0x00003538 in main (argc=1, argv=0xeffff5c4) at /Volumes/BruceDeuce/src/mozilla-19a/browser/app/nsBrowserApp.cpp:232

(gdb)

Are you sure you don't mean -mno-longcall to turn them off? Or would that be the default? Right now the compiler strings are

export CC="/opt/local/bin/gcc-apple-4.2 -flax-vector-conversions -mlongcall -mdynamic-no-pic -read_only_relocs suppress -mmacosx-version-min=10.4" export CXX="/opt/local/bin/g++-apple-4.2 -flax-vector-conversions -fpermissive -mlongcall -mdynamic-no-pic -read_only_relocs suppress -mmacosx-version-min=10.4"

(also:)

ld: warning: object file compiled with -mlong-branch which is no longer needed. To remove this warning, recompile without -mlong-branch: /opt/local/lib/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1/crt3.o

Now we're getting somewhere! With the following compiler strings

export CC="/opt/local/bin/gcc-apple-4.2 -flax-vector-conversions -mno-longcall -mdynamic-no-pic -read_only_relocs suppress -mmacosx-version-min=10.4" export CXX="/opt/local/bin/g++-apple-4.2 -flax-vector-conversions -fpermissive -mno-longcall -mdynamic-no-pic -read_only_relocs suppress -mmacosx-version-min=10.4"

we get:

Starting program: /Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFoxDebug.app/Contents/MacOS/firefox Reading symbols for shared libraries .................................................................+ done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries ................... done Reading symbols for shared libraries . done fcntl(F_SETLK) failed. errno = 35 WARNING: NS_ENSURE_TRUE(compMgr) failed: file /Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/xpcom/build/nsComponentManagerUtils.cpp, line 58 Reading symbols for shared libraries . done Reading symbols for shared libraries . done

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand. 0x0b332f60 in .objc_class_name_CTGradient () (gdb) bt

0 0x0b332f60 in .objc_class_name_CTGradient ()

1 0x0948c314 in js::CallObject::createForFunction (cx=0x487ab0, fp=0x296b128) at Stack.h:720

2 0x094e0208 in js::StackFrame::prologue (this=0x296b128, cx=0x487ab0, newType=false) at Stack.h:662

3 0x092d0394 in js::Interpret (cx=0x487ab0, entryFrame=0x296b128, interpMode=js::JSINTERP_NORMAL) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsinterp.cpp:1182

4 0x092e8070 in js::RunScript (cx=0x487ab0, script={> = {}, ptr = 0xefffa178}, fp=) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsinterp.cpp:326

5 0x092e9d5c in js::InvokeKernel (cx=0x487ab0, args={ = {usedRval_ = false, argv_ = 0x296b110}, argc_ = 3}, construct=js::NO_CONSTRUCT) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsinterp.cpp:381

6 0x092eabac in js::Invoke (cx=0x487ab0, thisv=@0x296b0e0, fval=@0x153b040, argc=3, argv=0x296b0e8, rval=0xefffa388) at jsinterp.h:109

7 0x0937af14 in js::BaseProxyHandler::call (this=, cx=0x487ab0, proxy=0x153b010, argc=3, vp=0x296b0d8) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsproxy.cpp:266

8 0x0944779c in js::CrossCompartmentWrapper::call (this=0x9d1ef3c, cx=0x487ab0, wrapper_=, argc=3, vp=0x296b0d8) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jswrapper.cpp:302

9 0x0936c3a8 in js::Proxy::call (cx=0x487ab0, proxy_=, argc=3, vp=0x296b0d8) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsproxy.cpp:2466

10 0x092eb85c in js::CallJSNative (cx=0x487ab0, native=0x9370010 <_ZL10proxy_CallP9JSContextjPN2JS5ValueE>, args=@0xefffa69c) at jscntxtinlines.h:364

11 0x092e99bc in js::InvokeKernel (cx=0x487ab0, args={ = {usedRval_ = false, argv_ = 0x296b0e8}, argc_ = 3}, construct=js::NO_CONSTRUCT) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsinterp.cpp:362

12 0x092d89a8 in js::Interpret (cx=0x487ab0, entryFrame=0x296b098, interpMode=js::JSINTERP_NORMAL) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsinterp.cpp:2331

13 0x092e8070 in js::RunScript (cx=0x487ab0, script={> = {}, ptr = 0xefffbb94}, fp=) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsinterp.cpp:326

14 0x092e9020 in js::ExecuteKernel (cx=0x487ab0, script=, scopeChain=, thisv=, type=js::EXECUTE_GLOBAL, evalInFrame=, result=0x0) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsinterp.cpp:512

15 0x092e93c8 in js::Execute (cx=0x487ab0, script={> = {}, ptr = 0xefffbb94}, scopeChainArg=, rval=0x0) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsinterp.cpp:550

16 0x091c7b6c in JS_ExecuteScript (cx=0x487ab0, objArg=, scriptArg=0x1536100, rval=0x0) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsapi.cpp:5549

17 0x091c7d2c in JS_ExecuteScriptVersion (cx=0x487ab0, objArg=, script=, rval=0x0, version=) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsapi.cpp:5558

18 0x08290aec in mozJSComponentLoader::ObjectForLocation (this=0x4877e0, aComponentFile=0x490e20, aURI=0x494480, aObject=0x490100, aLocation=0x490104, exception=0xefffbed0) at /Volumes/BruceDeuce/src/mozilla-19a/js/xpconnect/loader/mozJSComponentLoader.cpp:1067

19 0x08291f14 in mozJSComponentLoader::ImportInto (this=0x4877e0, aLocation=@0x48f220, targetObj=0x1518040, callercx=0x487ab0, _retval=0xefffc10c) at /Volumes/BruceDeuce/src/mozilla-19a/js/xpconnect/loader/mozJSComponentLoader.cpp:1281

20 0x08292ea0 in mozJSComponentLoader::Import (this=0x4877e0, registryLocation=@0x48f220, targetVal_=, cx=0x487ab0, optionalArgc=, retval=0xefffc478) at /Volumes/BruceDeuce/src/mozilla-19a/js/xpconnect/loader/mozJSComponentLoader.cpp:1185

21 0x0815e318 in nsXPCComponents_Utils::Import (this=, registryLocation=@0x48f220, targetObj=@0xefffc448, cx=0x487ab0, optionalArgc=0 '\0', retval=0xefffc478) at /Volumes/BruceDeuce/src/mozilla-19a/js/xpconnect/src/XPCComponents.cpp:4011

22 0x08dcd2bc in __NS_InvokeByIndex_P () at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_asm_ppc_rhapsody.s:98

23 0x081c055c in XPCWrappedNative::CallMethod (ccx=, mode=) at /Volumes/BruceDeuce/src/mozilla-19a/js/xpconnect/src/XPCWrappedNative.cpp:3139

24 0x081d3420 in XPC_WN_CallMethod (cx=0x487ab0, argc=1, vp=0x296b060) at /Volumes/BruceDeuce/src/mozilla-19a/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1488

25 0x092eb85c in js::CallJSNative (cx=0x487ab0, native=0x81d3030 , args=@0xefffc87c) at jscntxtinlines.h:364

26 0x092e9a7c in js::InvokeKernel (cx=0x487ab0, args={ = {usedRval_ = false, argv_ = 0x296b070}, argc_ = 1}, construct=js::NO_CONSTRUCT) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsinterp.cpp:369

27 0x092d89a8 in js::Interpret (cx=0x487ab0, entryFrame=0x296b020, interpMode=js::JSINTERP_NORMAL) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsinterp.cpp:2331

28 0x092e8070 in js::RunScript (cx=0x487ab0, script={> = {}, ptr = 0xefffdd74}, fp=) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsinterp.cpp:326

29 0x092e9020 in js::ExecuteKernel (cx=0x487ab0, script=, scopeChain=, thisv=, type=js::EXECUTE_GLOBAL, evalInFrame=, result=0x0) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsinterp.cpp:512

30 0x092e93c8 in js::Execute (cx=0x487ab0, script={> = {}, ptr = 0xefffdd74}, scopeChainArg=, rval=0x0) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsinterp.cpp:550

31 0x091c7b6c in JS_ExecuteScript (cx=0x487ab0, objArg=, scriptArg=0x151c100, rval=0x0) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsapi.cpp:5549

32 0x091c7d2c in JS_ExecuteScriptVersion (cx=0x487ab0, objArg=, script=, rval=0x0, version=) at /Volumes/BruceDeuce/src/mozilla-19a/js/src/jsapi.cpp:5558

33 0x08290aec in mozJSComponentLoader::ObjectForLocation (this=0x4877e0, aComponentFile=0x4490b0, aURI=0x488530, aObject=0x487f70, aLocation=0x487f74, exception=0x0) at /Volumes/BruceDeuce/src/mozilla-19a/js/xpconnect/loader/mozJSComponentLoader.cpp:1067

34 0x082936fc in mozJSComponentLoader::LoadModule (this=0x4877e0, aFile=@0x448804) at /Volumes/BruceDeuce/src/mozilla-19a/js/xpconnect/loader/mozJSComponentLoader.cpp:496

35 0x08d8c638 in nsComponentManagerImpl::KnownModule::Load (this=0x448800) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/components/nsComponentManager.cpp:699

36 0x08d8efac in nsFactoryEntry::GetFactory (this=0x448830) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/components/nsComponentManager.cpp:1749

37 0x08d8f4dc in nsComponentManagerImpl::CreateInstanceByContractID (this=0x421670, aContractID=0x972afa8 "@mozilla.org/embedcomp/prompt-service;1", aDelegate=0x0, aIID=@0x998c7b0, aResult=0xefffe2fc) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/components/nsComponentManager.cpp:1031

38 0x08d94014 in nsComponentManagerImpl::GetServiceByContractID (this=0x421670, aContractID=0x972afa8 "@mozilla.org/embedcomp/prompt-service;1", aIID=@0x998c7b0, result=0xefffe414) at /Volumes/BruceDeuce/src/mozilla-19a/xpcom/components/nsComponentManager.cpp:1427

39 0x08d08efc in nsGetServiceByContractID::operator() (this=, aIID=, aInstancePtr=0xefffe414) at /Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/xpcom/build/nsComponentManagerUtils.cpp:62

40 0x069afc14 in _ZL19ProfileLockedDialogP7nsIFileS0_P18nsIProfileUnlockerP19nsINativeAppSupportPP14nsIProfileLock (aProfileDir=0x416fb0, aProfileLocalDir=0x417030, aUnlocker=0x0, aNative=, aResult=0xefffe9d8) at nsCOMPtr.h:1203

41 0x069b2a80 in _ZL19ProfileLockedDialogP17nsIToolkitProfileP18nsIProfileUnlockerP19nsINativeAppSupportPP14nsIProfileLock (aProfile=0x416960, aUnlocker=0x0, aNative=0x40ba40, aResult=0xefffe9d8) at /Volumes/BruceDeuce/src/mozilla-19a/toolkit/xre/nsAppRunner.cpp:1862

42 0x069b53c4 in _ZL13SelectProfilePP14nsIProfileLockP24nsIToolkitProfileServiceP19nsINativeAppSupportPbP19nsACString_internal (aResult=0xefffe9d8, aProfileSvc=, aNative=0x40ba40, aStartOffline=, aProfileName=0xefffea10) at /Volumes/BruceDeuce/src/mozilla-19a/toolkit/xre/nsAppRunner.cpp:2319

43 0x069bb70c in XREMain::XRE_mainStartup (this=0xefffe9c8, aExitFlag=0xefffe8ec) at /Volumes/BruceDeuce/src/mozilla-19a/toolkit/xre/nsAppRunner.cpp:3475

44 0x069bc31c in XREMain::XRE_main (this=0xefffe9c8, argc=, argv=, aAppData=0x5128) at /Volumes/BruceDeuce/src/mozilla-19a/toolkit/xre/nsAppRunner.cpp:3875

45 0x069bc7c8 in XRE_main (argc=1, argv=0xeffff4fc, aAppData=0x5128, aFlags=) at /Volumes/BruceDeuce/src/mozilla-19a/toolkit/xre/nsAppRunner.cpp:4084

46 0x00003eac in main (argc=1, argv=0xeffff4fc) at /Volumes/BruceDeuce/src/mozilla-19a/browser/app/nsBrowserApp.cpp:174

(gdb)

So the browser does at least get further in. JavaScript shell appears to work fine, though, so something else must be going on.

I examined the gcc sources and it is impossible to have gcc not generate the stub islands when targetting 10.4 or earlier. All decisions that gcc takes based on the mmacosx-version-min switch are related to the linker (it always assumes the old 32 bit only linker) or unwinding (which would affect OS X crash reports and gdb). Hoping it doesn't break debugging too seriously (we might even try to build the Xcode 3 gdb for 10.4) I propose to force gcc to build as if it were for 10.5 which would make it assume ld64, which in fact is right. So now its time to do some real nasty hacking! To the command line you would have to add the following switches: "-mmacosx-version-min=10.5 -D__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__=1040 -Wl,-macosx_version_min,10.4"

Forgot to add that -mlongcall tells gcc to generate the islands while -mno-longcall lets it rely on the linker to do that where necessary. I didn't understand that completely. Now gcc (wrongly) assumes that when building for 10.4 it's always the old 32 bit linker that is used and generates stub calls for all library calls while when targetting 10.5 it does simply generate long branches that ld64 can replace with local branches if possible or leave it like that.

Trying to build using gcc 4.7 and the hacks from comment 180. In order to have configure working correctly you have to suppress all warnings by adding "-w" to the compiler command line because some tests use Werror. In order to be able to link when mmacosx-version-min is set to 10.5 you also need to have the objects crt1.10.5.o and dylib1.10.5.o in your {SDKROOT}/usr/lib . You can create symlinks to the existing crt1.o and dylib1.o objects. But you may want to use the ones that I attached as I rebuilt (Csu-79 Apple open source project) them using the command line parameters from comment 180 (some build fixes were also required).

In the attached archive all required crt files are rebuilt with the command line from comment 180. crt2, crt3, crttme, crttms go into /opt/local/lib/gcc46/gcc/ppc-apple-darwin8/4.6.3/ and the others as described above.

Well, and add -Wl,-lcrt3.o to the command line so that it is now: "-mmacosx-version-min=10.5 -D__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__=1040 -Wl,-macosx_version_min,10.4,-lcrt3.o". And replace /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libgcc_s.10.5.dylib with /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libgcc_s.10.4.dylib, and /opt/local/lib/gcc46/libgcc_ext.10.5.dylib with /opt/local/lib/gcc46/libgcc_ext.10.4.dylib. Alternatively addin "-static-libgcc" to the compiler command line might work as well.

In case those hacks prove to produce a working TFF they should be refactored as a patch to MacPorts and fink gcc packages.

Before I do this, let me make sure I have the steps understood:

• Compiler command lines should be export CC="/opt/local/bin/gcc-mp-4.6 -flax-vector-conversions -mno-longcall -mdynamic-no-pic -read_only_relocs suppress -mmacosx-version-min=10.5 -D__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__=1040 -Wl,-macosx_version_min,10.4"

export CXX="/opt/local/bin/g++-mp-4.6 -flax-vector-conversions -fpermissive -mno-longcall -mdynamic-no-pic -read_only_relocs suppress -mmacosx-version-min=10.5 -D__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__=1040 -Wl,-macosx_version_min,10.4"

• Our builder instructions will be, after installing MacPorts gcc 4.6.3, download crt.zip and
  • put *.10.5.o in /Developer/SDKs/MacOSX10.4u.sdk/usr/lib
  • the other 4 go in /opt/local/lib/gcc46/gcc/ppc-apple-darwin8/4.6.3/

Is this right? Also,

• What do you mean by "You can create symlinks to the existing crt1.o and dylib1.o objects" ?
• What were the "build fixes" you had to do?

Sounds like a bug should be filed against the portfile, too, so that the build process is fixed to support this.

Oh, I just saw your second post. So now I'm really confused. Let me try again:

• Compiler command lines:

export CC="/opt/local/bin/gcc-mp-4.6 -flax-vector-conversions -mno-longcall -mdynamic-no-pic -read_only_relocs suppress -mmacosx-version-min=10.5 -D__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__=1040 -Wl,-macosx_version_min,10.4,-lcrt3.o"

export CXX="/opt/local/bin/g++-mp-4.6 -flax-vector-conversions -fpermissive -mno-longcall -mdynamic-no-pic -read_only_relocs suppress -mmacosx-version-min=10.5 -D__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__=1040 -Wl,-macosx_version_min,10.4,-lcrt3.o"

(+/- -static-libgcc, though wouldn't that be a problem for the dylibs?)

• Isn't there a better way to deal with the SDK changes than wrecking the 10.5 dylibs, even though they are not likely to ever be needed? It sounds like what you're doing is replacing the 10.5 dylibs with the 10.4 dylibs.

• Our builder instructions will be, after installing MacPorts gcc 4.6.3, download crt.zip and

  • put *.10.5.o in /Developer/SDKs/MacOSX10.4u.sdk/usr/lib
  • the other 4 go in /opt/local/lib/gcc46/gcc/ppc-apple-darwin8/4.6.3/

Is this right?

The 10.5 and 10.4 libgcc dylibs are just stubs that make the linker search for those symbols that are defined in the stubs in the real iibgcc_s.1.dylib that the stubs have as install name, which will be either the system libgcc or the compiler's libgcc. That way only those symbols that are missing in the system libgcc will be resolved with the compiler's libgcc. So until we have gcc fixed up there's no other way than replacing the stubs with the ones we need. Statically linking with the compiler's libgcc might work alternatively. Like I said I'd definitely leave out "-mno-longcall". The macosx-version-min switch will take care of that. And don't forget to add "-w" as otherwise configure won't succeed! But beware that there is a bug in the build system for cairo as it isn't built with the normal CFLAGS and the SDK is also missing. I attached a patch to fix this but somehow it doesn't (always) add the SDK to the MOZ_CAIRO_CFLAGS in config/autoconf.mk but that won't affect you when you build in 10.4 . The modified Csu-79 should somehow be integrated with the MacPorts and fink gcc packages, but first this needs to be tested at all! To get Csu compiled I had to define private_extern to attribute((visibility("hidden"))) as gcc doesn't seem to support it. And the file extension of the assembly files had to be changed from .s to .S in order to have the compiler preprocess them. And obviously the macosx-version-min for 10.4 had to be removed where it was applied. For the other crts I rebuilt libgcc changing the flags for compiling the crts from -mlongcall to the hacked one.

I wonder how that "Like I said" came in there...

I haven't had a chance to dump the symbols to find out why, but I'm curious why a) the 10.5 dylib is needed at all on 10.4 and b) why we couldn't use the 10.5 dylib if it's just going to look it up in system libgcc anyway, thus allowing us not to have to muck with hacking the SDK.

I get the compiler command line changes now, but what about: - Our builder instructions will be, after installing MacPorts gcc 4.6.3, download crt.zip and - put *.10.5.o in /Developer/SDKs/MacOSX10.4u.sdk/usr/lib - the other 4 go in /opt/local/lib/gcc46/gcc/ppc-apple-darwin8/4.6.3/

Is this right?

There is no 10.5 dylib, there's just one libgcc dylib but the 10.4 and 10.5 stubs give the linker a hint where to look for the symbols that are missing in the system libgcc. And gcc, depending on macosx-version-min decides against which stub to link. You cannot use the 10.5 stub because otherwise dyld might be unable to resolve some symbols that aren't in the 10.4 libgcc but which are in the 10.5 dylib. Otherwise you understood correctly, but the instructions are primarily for you to test. In case that works we'd have to create patches against libgcc, creating a way to tell it that ld64 is used for linking even on 10.4.

I'm preparing a patch against gcc, that works around modifying system files.

I see. I'll try this on Friday (way too much going on at work to sit down with this today).

Have found something interesting: the ld64 project contains 188 unit tests that test the whole toolchain. So far gcc 4.0 fails one test gcc 4.2 passes and gcc 4.7 fails 4 tests that gcc 4.2 passes. There are two tests that always fail.

Have now rebuilt gcc 4.7 with the attached patch applied. Also rebuilt Csu-79 using that gcc 4.7 and attached the resulting objects that have to be installed into "/opt/local/lib/gcc46/gcc/ppc-apple-darwin8/4.6.3/" as that path is the first to be searched for libraries, so Apple built crts don't have to be replaced. Building and installing those crts should in fact be part of the compiler bootstrapping.

Here the crts.

Will now try a build of TFF 19 in 10.5 targetting 10.4 .

It now gets loaded on 10.5 but crashes in a wrong branch island, which was generated by the linker exclusively. For example there were three different islands generated for the call to mozilla::DebugOnly::DebugOnly(bool const&). Those three islands shall guarantee that at least one island can be reached by a local branch without having to load the branch target address first. Now the first two islands are correct but the third branches to a wrong address. That wrong code was generated by our linker, ld64. The object file containing the third wrong call doesn't even contain a call to mozilla::DebugOnly::DebugOnly(bool const&) but only to mozilla::DebugOnly::DebugOnly(unsigned long long const&), but I don't know how that template stuff is supposed to be treated.

gdb output from within all three islands: 0x81ae878 <_ZN7mozilla9DebugOnlyIbEC1ERKb$island>: b 0x73e9b28 <_ZN7mozilla9DebugOnlyIbEC1ERKb> 0x8fbac04 <_ZN7mozilla9DebugOnlyIbEC1ERKb$island$2>: b 0x73e9b28 <_ZN7mozilla9DebugOnlyIbEC1ERKb> 0x9dbd3dc <_ZN7mozilla9DebugOnlyIbEC1ERKb$island$3>: b 0xb3e9b28 <.objc_class_name_CTGradient+13069948>

All three islands disassembled:

__ZN7mozilla9DebugOnlyIbEC1ERKb$island$3: 02a133dc b 0x403fb28

__ZN7mozilla9DebugOnlyIbEC1ERKb$island$2: 01c10c04 b __ZN7mozilla9DebugOnlyIbEC1ERKb

__ZN7mozilla9DebugOnlyIbEC1ERKb$island: 00e04878 b __ZN7mozilla9DebugOnlyIbEC1ERKb

As you see in my mozconfig I built without optimization but with debugging switched off. I suspect that AuroraFox only used to work because I never build unoptimized and maybe also because I built with a separate js shared lib, both of which reduce XUL size and hence the number of islands generated.

So are we dead, then? I'm not sure how we can work around bad codegen.

The other possibility is, perhaps XUL is just too big for PPC ld64 now (in debug mode, at least). We know that when Mozilla had trouble with the Windows linker not dealing with oversize objects that they were able to move things like media codecs into separate dylibs, and it sounds like you have a separate js dylib. Does that sound plausible? If so, what changes did you make?

Uh, separate DLLs, but you know what I mean.

Building with a separate js dylib is done by simply adding --enable-shared-js to the mozconfig.

Hey guys

FWIW i've been running into bad island branches in SeaMonkey beta building as well even using the latest MacPorts version of ld64 and gcc 4.7.2.

Disassembling and following the island branch in the following case takes me right into the middle of a list of class names ???? crazy !

Seems that the linker is trying a jump too far and overflowing/underflowing some address calculating arithmetic ?

Just thought I'd let you know you're not alone

(gdb) bt

0 0x0a8f7490 in .objc_class_name_CrApplication ()

1 0x09471ca8 in js::detail::HashTable, js::HashMap, js::SystemAllocPolicy>::MapHashPolicy, js::SystemAllocPolicy>::HashTable (this=0x1ccb928, ap={}) at HashTable.h:340

2 0x0947174c in js::HashMap, js::SystemAllocPolicy>::HashMap (this=0x1ccb928, a={}) at HashTable.h:1026

3 0x09470b7c in js::SPSProfiler::SPSProfiler (this=0x1ccb924, rt=0x1ccb000) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/js/src/vm/SPSProfiler.cpp:25

4 0x091863c4 in JSRuntime::JSRuntime (this=0x1ccb000) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/js/src/jsapi.cpp:863

5 0x091871d4 in JS_Init (maxbytes=268435456) at Utility.h:500

6 0x07b360d8 in XPCJSRuntime::XPCJSRuntime (this=0x848600, aXPConnect=0x39d380) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/js/xpconnect/src/XPCJSRuntime.cpp:2393

7 0x07b364e8 in XPCJSRuntime::newXPCJSRuntime (aXPConnect=0x39d380) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/js/xpconnect/src/XPCJSRuntime.cpp:2490

8 0x07af3034 in nsXPConnect::nsXPConnect (this=0x39d380) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/js/xpconnect/src/nsXPConnect.cpp:87

9 0x07af33ec in nsXPConnect::GetXPConnect () at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/js/xpconnect/src/nsXPConnect.cpp:147

10 0x06fbfe5c in nsContentUtils::Init () at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/content/base/src/nsContentUtils.cpp:356

11 0x06be8c74 in nsLayoutStatics::Initialize () at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/layout/build/nsLayoutStatics.cpp:150

12 0x06be0d44 in Initialize () at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/layout/build/nsLayoutModule.cpp:386

13 0x08a41524 in nsComponentManagerImpl::KnownModule::Load (this=0x329b50) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/xpcom/components/nsComponentManager.cpp:708

14 0x08a43cdc in nsFactoryEntry::GetFactory (this=0x329b90) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/xpcom/components/nsComponentManager.cpp:1749

15 0x08a420d8 in nsComponentManagerImpl::CreateInstanceByContractID (this=0x31f740, aContractID=0x9556180 "@mozilla.org/js/xpc/ContextStack;1", aDelegate=0x0, aIID=@0x96e2440, aResult=0xbfffdfb4) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/xpcom/components/nsComponentManager.cpp:1031

16 0x08a42c80 in nsComponentManagerImpl::GetServiceByContractID (this=0x31f740, aContractID=0x9556180 "@mozilla.org/js/xpc/ContextStack;1", aIID=@0x96e2440, result=0xbfffe0c8) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/xpcom/components/nsComponentManager.cpp:1427

17 0x089d34f0 in CallGetService (aContractID=0x9556180 "@mozilla.org/js/xpc/ContextStack;1", aIID=@0x96e2440, aResult=0xbfffe0c8) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla-using-gcc47-seamonkey-for-ppc/mozilla/xpcom/build/nsComponentManagerUtils.cpp:62

18 0x089d3bcc in nsGetServiceByContractID::operator() (this=0xbfffe0fc, aIID=@0x96e2440, aInstancePtr=0xbfffe0c8) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla-using-gcc47-seamonkey-for-ppc/mozilla/xpcom/build/nsComponentManagerUtils.cpp:246

19 0x089d208c in nsCOMPtr_base::assign_from_gs_contractid (this=0xbfffe170, gs={mContractID = 0x9556180 "@mozilla.org/js/xpc/ContextStack;1"}, iid=@0x96e2440) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla-using-gcc47-seamonkey-for-ppc/mozilla/xpcom/build/nsCOMPtr.cpp:92

20 0x07506a6c in nsCOMPtr::nsCOMPtr (this=0xbfffe170, gs={mContractID = 0x9556180 "@mozilla.org/js/xpc/ContextStack;1"}) at nsCOMPtr.h:586

21 0x07d194b0 in nsWindowWatcher::GetJSContextFromCallStack () at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp:2121

22 0x07d1613c in nsWindowWatcher::URIfromURL (aURL=0x9615590 "chrome://mozapps/content/profile/profileSelection.xul", aParent=0x0, aURI=0xbfffe3c8) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp:1379

23 0x07d127fc in nsWindowWatcher::OpenWindowInternal (this=0x31f2f0, aParent=0x0, aUrl=0x9615590 "chrome://mozapps/content/profile/profileSelection.xul", aName=0x9525b0c "_blank", aFeatures=0x9525b14 "centerscreen,chrome,modal,titlebar", aCalledFromJS=false, aDialog=true, aNavigate=true, argv=0x375e30, _retval=0xbfffe77c) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp:512

24 0x07d124f0 in nsWindowWatcher::OpenWindow (this=0x31f2f0, aParent=0x0, aUrl=0x9615590 "chrome://mozapps/content/profile/profileSelection.xul", aName=0x9525b0c "_blank", aFeatures=0x9525b14 "centerscreen,chrome,modal,titlebar", aArguments=0x375dd0, _retval=0xbfffe77c) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp:399

25 0x068e4458 in ShowProfileManager (aProfileSvc=0x31c180, aNative=0x31b970) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/toolkit/xre/nsAppRunner.cpp:1903

26 0x068e654c in SelectProfile (aResult=0xbfffebfc, aProfileSvc=0x31c180, aNative=0x31b970, aStartOffline=0xbfffecdc, aProfileName=0xbfffec34) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/toolkit/xre/nsAppRunner.cpp:2310

27 0x068e8708 in XREMain::XRE_mainStartup (this=0xbfffebec, aExitFlag=0xbfffeb8c) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/toolkit/xre/nsAppRunner.cpp:3450

28 0x068e9dcc in XREMain::XRE_main (this=0xbfffebec, argc=1, argv=0xbffff6d4, aAppData=0x50d0) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/toolkit/xre/nsAppRunner.cpp:3845

29 0x068ea074 in XRE_main (argc=1, argv=0xbffff6d4, aAppData=0x50d0, aFlags=0) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla/toolkit/xre/nsAppRunner.cpp:3935

30 0x000034a0 in do_main (exePath=0xbffff1cc "/Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/mozilla-using-gcc47-seamonkey-for-ppc/mozilla/dist/SeaMonkey.app/Contents/MacOS/", argc=1, argv=0xbffff6d4) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/suite/app/nsSuiteApp.cpp:173

31 0x00003720 in main (argc=1, argv=0xbffff6d4) at /Applications/-PROJECTS-/SeaMonkey-PPC/-REPOSITORY-/comm-beta/suite/app/nsSuiteApp.cpp:261

That backtrace is very similar to what I'm getting now.

Might not be too difficult to fix that bug after all. The wrong branch island target address is exactly 0x4000000 (=64MB) off at least in the case I examined. I'd expect to be able to fix that.

Digging around, I found https://developer.apple.com/library/mac/#documentation/developertools/conceptual/MachORuntime/Reference/reference.html which says that Mach-O relocations only have a 24-bit address field: dyld can't handle single code segments larger than 16 MB. See also http://lists.apple.com/archives/carbon-development/2004/Jun/msg00350.html . (The compiler can of course try to break things into multiple segments, but I don't know if it does.)

Breaking XUL into smaller libraries may be the best thing to try next.

W/r/t comment 204, it's not that ld generated the wrong address, probably; I think it's too big of a displacement for a single branch, i.e., the code should be lis/ori/mtctr/bctr instead of a simple b. But that makes the island bigger, and the linker may not be able to cope with that as written. Maximum displacement is 32MB and the branch looks like it's out of range:

perl -e 'print 32*1024*1024' 33554432 perl -e 'print hex("09dbd3dc")-hex("073e9b28")' 43858100

(the 07... is because that's where the branch should go). This supports the "too damn big" theory.

We could hack ld in theory to generate or at least accept larger branch islands. We do this in JavaScript already, as it happens (the stanzas), but this seems scary because I don't know how gcc would deal with that.

So I'm with Ben, we need to break libxul down unless Tobias thinks hacking the compiler is possible. Issue 169 was just the canary in the coal mine and I guess we've simply been lucky so far that the browser could still stand up.

Mozilla did look into this when they had PGO linker problems on Windows, as mentioned. Not all of these were actually implemented, but here are the ones that actually have patches: https://bugzilla.mozilla.org/show_bug.cgi?id=709657 https://bugzilla.mozilla.org/show_bug.cgi?id=709721 (and https://bugzilla.mozilla.org/show_bug.cgi?id=718485)

Also, we could totally rip out all the WebGL stuff since it doesn't work on 10.4 anyway (but this might not be a good option for AuroraFox or SeaMonkeyPPC): https://bugzilla.mozilla.org/show_bug.cgi?id=709914

and of course https://bugzilla.mozilla.org/show_bug.cgi?id=609976 though this is really just burning into the code what --enable-shared-js does anyway.

(and the island should, optimally, be larger than that for G5; G5's optimal code would be lis/ori/mtctr/nop/nop/nop/nop/bctr)

From the ld64 sources:

// // PowerPC can do PC relative branches as far as +/-16MB. // If a branch target is >16MB then we insert one or more // "branch islands" between the branch and its target that // allows island hopping to the target. // // Branch Island Algorithm // // If the __TEXT segment < 16MB, then no branch islands needed // Otherwise, every 14MB into the __TEXT segment a region is // added which can contain branch islands. Every out-of-range // bl instruction is checked. If it crosses a region, an island // is added to that region with the same target and the bl is // adjusted to target the island instead. // // In theory, if too many islands are added to one region, it // could grow the __TEXT enough that other previously in-range // bl branches could be pushed out of range. We reduce the // probability this could happen by placing the ranges every // 14MB which means the region would have to be 2MB (512,000 islands) // before any branches could be pushed out of range. //

So ld64 is supposed to generate island hopping. Islands should be placed in distances of approx. 14MB and one function call may result in hopping over multiple islands. So it's definitely a calculation fault in ld64. It should be easy to debug ld64.

...We could hack ld in theory to generate or at least accept larger branch islands....

What about setting up a string of islands to get to where you want ?

Iterating in additional islands in the linker may be easier than reworking what happens on an island ?

Apart from the G5 scheduling optimizations it's everything implemented but there's just a bug to eliminate. So it's not hacking but accurate fixing and/or optimizing what is to be done.

Sure is nice to have someone that knows the internals of gcc and the linker

Tobias is the man !

Then clearly ld is failing to meet one of its invariants somewhere. The comments have

the region would have to be 2MB (512,000 islands) // before any branches could be pushed out of range

so we must be at that point. If you compare the actual opcode for all three of those branches, I bet they are all the same; the difference is the memory location.

So assuming that comment block is accurate, one thought would be to reduce the spacing from 14MB to, say, 8 or 10. This would cause more islands, but that's better than building nothing.

Debug output from ld64: ld: 17866 branch islands required in 3 regions

Guess not. But at minimum we should instrument ld to generate warnings or errors if it spits out an out of range branch.

Bug fixed!!! Typing this from TFF 19. Just look at the patchfile...

Can't test in 10.4 as I don't yet have a 4.6/4.7 libstdc++ for 10.4

That's okay, I'll try it tomorrow. I'll rebuild ld tonight. This goes against Apple's sources for 97.17, right?

I still recommend using the patches from comment 193 and comment 194 as they make gcc produce the best code for ld64 even when targetting 10.4 . I also saw in the gcc sources that when targetting 10.4.5 and lower some libstdc++ feature(s) is/are disabled, so maybe adding -mmacosx-version-min=10.4.6 to the compiler command line would be a good idea.

The ld64 patch, as you see in the patchfile, goes against the MacPorts patched ld64-97.17 , but should apply to the clean sources as well.

Filed a bug report with patch to MacPorts (ticket 37300) and Apple.

Great job Tobias !

How could Apple or whoever have missed something like that ? Anyhow ...

Any idea how long before the MacPorts folks turn around a new port update ?

I see that ld is an Xcode Project file, tried a quick run at a build with your patch installed from Xcode and it churns out tons of errors. Guess I'll have to brush up on Xcode.

You can apply the patch to the MacPorts version. "sudo port configure ld64" to prepare anything for the build "port work ld64" to find out where the sources were extracted to. Apply the patch "sudo port destroot" to build and install to a temporary directory The built files will be placed in a folder "destroot" next to the source directory (ld64-97.17). I didn't yet find a way to overwrite the currently installed port, so you'll have to manually copy the ld executable to /opt/local/bin (maybe also /opt/local/libexec/ld64).

Tobias, thanks I'll give it a try

Good news and bad news:

• Good news: I replaced /opt/local/bin/ld with the new one (and ticked the version in Options.* to 97.18, which you might want to do in your MacPorts patch). Then I just told it to relink XUL, and the app starts ...
• and Bad news: cairo looks like it got modified; it's trying to instantiate a CoreText font in some fashion that 10.4 CoreText does not like. But that's my problem to fix.

This was just with 4.2, so I'm going to flip it over and rebuild with 4.6.3 tonight to make sure that works too.

(note to self: #0 0x9022f5d4 in TFont::TFont ()

1 0x9022f548 in CTFontCreateWithGraphicsFont ()

2 0x08fd22cc in _moz_cairo_quartz_font_face_create_for_cgfont (font=0x1dc2ecd0) at /Volumes/BruceDeuce/src/mozilla-19a/gfx/cairo/cairo/src/cairo-quartz-font.c:373

3 0x08e7d62c in gfxMacFont::gfxMacFont (this=0x1dc2eb10, aFontEntry=0x1dc2e980, aFontStyle=, aNeedsBold=false) at /Volumes/BruceDeuce/src/mozilla-19a/gfx/thebes/gfxMacFont.cpp:43

... bug 715798 https://bug715798.bugzilla.mozilla.org/attachment.cgi?id=673247

And there is no more crash on exit! So this solves issue 169, as predicted. Beer for Tobias!

/opt/local/bin/gcc-mp-4.6 -print-prog-name=ld -v @(#)PROGRAM:ld PROJECT:ld64-97.18

SeaMonkey PPC lives !

patched and built ld64 using Tobias' fix and am typing this from 2.15b4.

Thanks much guys

ps I've been using gcc version 4.7.2 (MacPorts gcc47 4.7.2_2) - works great

Other than a mistake I made fixing gfxMacPlatformFontList.mm, no major issues. Up and running, 4.6.3, 97.18.

Opt builds don't yet work, though. For the G5 I have, currently, export CC="/opt/local/bin/gcc-mp-4.6 -flax-vector-conversions -O3 -mcpu=7450 -mtune=G5 -falign-loops=16 -falign-functions=16 -falign-labels=16 -falign-jumps=16 -mmfcrf -mpowerpc-gpopt -read_only_relocs suppress -force_cpusubtype_ALL -mdynamic-no-pic -D_PPC970_ -mmacosx-version-min=10.4" export CXX="/opt/local/bin/g++-mp-4.6 -flax-vector-conversions -fpermissive -O3 -mcpu=7450 -mtune=G5 -falign-loops=16 -falign-functions=16 -falign-labels=16 -falign-jumps=16 -mmfcrf -mpowerpc-gpopt -read_only_relocs suppress -force_cpusubtype_ALL -mdynamic-no-pic -D_PPC970_ -mmacosx-version-min=10.4"

However, it's not linking double_conversion.o into mozlibglue, so JS can't build (but there is a double_conversion.o). This obviously worked fine in debug mode. What are your opt compiler strings?

There's just "-mcpu=7400 -mtune=G5" added to the compiler arguments. But in order to build 32 bit objects for a G5 (as is done for WebKit and AuroraFox libmozjs.dylib) you have to pass "-mcpu=970 -m32". Otherwise (like you've probably noticed) gcc will think you'd want 64 bit objects as the 970 is a 64 bit CPU. Do you really need "-force_cpusubtype_ALL"? I'd think that in case you don't do runtime CPU feature detection that can just cause problems because it's not correct. Was this necessary to have the old linker link the ppc970 objects with ppc libraries/objects? I'd also recommend to leave "-mmfcrf -mpowerpc-gpopt" out as this is already done by "-mcpu=970".

I think the -m32 is the part I'm missing. I need (or at least I did with 4.0.1) the -force_cpusubtype_ALL because the assembler compiled the VPX AltiVec objects as generic "ppc" -- I'll see if that's still the case with the new bintools as. I'll try that later tonight (checking E-mail between meetings).

libmozglue should have all the mfbt stuff in it (it does in DEBUG) and it doesn't even with -m32. So something else is afoot. It's clearly related to the compiler arguments, but even simply -flax-vector-conversions -fpermissive -O3 -mcpu=7450 -mtune=G5 won't do it.

It's one of the options, not the compile string. I'm just going to start cutting them out one by one until it works.

It's the -enable-strip/-enable-install-strip options. I guess strip is a little overzealous on the new object files this generates. Without those, all the symbols now appear correctly in libmozglue.

I didn't ever build Aurora with strip options so I didn't know this. In order to specify the output architecture of objects the assembly must contain a machine directive, for just Altivec this would be ".machine ppc7400" and for the G5 ".machine ppc970" obviously. For example TrampolinePPCOSX.S (note that it must be 'S', not 's', in order to have gcc automatically run the preprocessor on the file) in Aurora contains the following lines at the top (gcc has to be run with "-mcpu=970" in order to have _ARCH_PWR4, defined which I use instead of PPC970):

if defined(_ARCH_PWR4)

warning building optimized for G5/POWER4

.machine ppc970

endif

But I only need this in order to be able to build a multi-arch (ppc7400/ppc970) static js library, because libtool isn't aware of the concept of arches and subarches (and lipo is only partially and needs this workaround). This isn't necessary for building multi-arch executables or dylibs.

I had "-force_cpusubtype_ALL" added to the libvpx Makefile only but now I removed that and added ".machine ppc7400" to all Altivec assembler source files. Not generally passing "-force_cpusubtype_ALL" has the big advantage that the OS wouldn't allow to start a version of TenFourFox that isn't compatible with the CPU.

True, except that the 970 version I build is -mcpu=7450 -mtune=G5 anyway.

Doesn't Tiger support the subarch ppc970?

Yes, but making an -mcpu=G5 build was notoriously unstable. Might have been gcc 4.0.1, though.

In any case, G5 opt build is now working. Last step before I close is to build a portable opt build and/or write a builder script to copy libraries and change the dyld executable path.

WebKit built with gcc 4.2 and -mcpu=G5 does indeed work as well as the G5 optimized libmozjs dylib which is built with gcc 4.7 and -mcpu=970 -m32. I noticed that gcc 4.6 (maybe FSF gcc in general) and later define _ARCH_PPC64 when building with just -mcpu=970 and concluded that there must be something wrong as I wanted 32 bit G5 optimized. As I wanted to be sure and didn't have a G5 machine to test on I chose to add -m32. Now -m32 and -m64 are supposed to select Darwin or Darwin64 ABI. Turns out -m32 does something more in also disabling the use of 64 bit instructions/GPRs, what can be controlled directly by setting -m(no-)powerpc64. I compiled a simple test program that does 64 bit integer division using different compiler switches. The settings "-mcpu=970" and "-mcpu=7450 -mpowerpc64" result in a binary that does native 64 bit integer division even in the 32 bit Darwin ABI, with the architecture of the output file being set to ppc970 in both cases. Passing "-m32" reverts "-mpowerpc64" when passed last (don't know if gcc is really supposed to behave like this). The conclusion is that _ARCH_PPC64 does just mean that the use of 64 bit instructions/GPRs is enabled and has nothing to do with the ABI.

Given the not too scarce use of uint64_t in the js library and the whole codebase building with -mpowerpc64 or -mcpu=970 should result in some speed improvement on G5s. I'll compare JavaScript performance.

Now I know why I had to add -m32; either gcc produces wrong mach-o objects or ld64 links them wrong and dyld returns "unknown local relocation type" when trying to load the ppc970 dylib.

So are you saying -mcpu=G5 -m32 -mpowerpc64 ?

Incidentally, as a followup to strip, I noticed that the new libxul created by this is almost 70MB in the G5 version (!). However, it can't be stripped; 10.4 strip actually barfs on it and refuses to alter the file. So that's that.

-mcpu=G5 implicates -mpowerpc64 which is reverted by -m32 . So "-mcpu=G5 -m32 -mpowerpc64" should be the same as just -mpcu=G5. Although I didn't test it "-mcpu=G5 -mno-powerpc64" should be equal to "-mcpu=G5 -m32".

You need to use later cctools (equal to binutils), for example from the MacPorts port cctools.

-mcpu=G5 doesn't enable Darwin64 ABI as I first assumed. So -m32 isn't necessary even with -mcpu=G5. WebKit built with gcc-4.2 and -mcpu=G5 (without adding -m32) does work, so I don't know where the acutal problem is that I get when building libmozjs.dylib as fat binary. Might be related to libxpcom. Additionally it does only work when ppc970 comes before ppc7400.

I already tried that. /opt/local/bin/strip actually makes a defective XUL (rather than just giving up):

XPCOMGlueLoad error 4:0 for file /Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFox.app/Contents/MacOS/libxpcom.dylib: Symbol not found: _CC_MD5_Final Referenced from: /Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFox.app/Contents/MacOS/XUL Expected in: /Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFox.app/Contents/MacOS/XUL

Couldn't load XRE functions.

This is probably due to the phony CommonCrypto stubs I put in to get Chromium IPC to work on 10.4.

The mozilla sources pass "-x -S" as parameters to strip. Are you using the same?

D'oh.

Regarding the mcpu=G5 or mcpu=970 problems I found some other people have also had problems with that in the past and finally this: http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01061.html So that might eventually get fixed.

In order to have it documented in this context: By merging the changes from gcc 4.2.2 until 4.2.4 into Apple's gcc 4.2 (based on 4.2.1) the two compiler issues I had with Leopard WebKit can be solved. One was that ftree-vrp caused wrong code in a certain loop constellation and the other was mcpu=970 (or mcpu=G5), which includes mpowerpc64 caused wrong behaviour on some websites. So now using MacPorts gcc 4.2.4 Apple build 5666.3 I don't have any remaining issues with that compiler.

Regarding the problem that dyld has with loading the mcpu=G5 (respectively mpowerpc64) built libmozjs.dylib I found out that by compiling without optimization (-O0) that issue is gone. However I was unable to determine which optimization exactly caused this problem, as it persists even when I turn off all switchable optimizations and optimization passes. So that is actually a very different problem from the ones I had with Leopard WebKit.

I could now solve the mpowerpc64 problem; the problem arises when compiling with optimization level >= 1, mpowerpc64 (or mcpu=G5 or mcpu=970) and mdynamic-no-pic. Under that circumstances the assembler generates a relocation of type LO14, meaning 14 bits that represent bits 2 - 15 of the effective address (lowest two bits are forced to zero), which is meant to be used for some types of 64 bit loads and stores. Unfortunately dyld doesn't support that relocation type any more beginning with 10.4 (while until 10.3 dyld was part of the cctools project it became a project of its own in 10.4, similar to what happened in the transition from ld to ld64). Looking at the dyld sources I understood that distinguishing between LO14 and LO16 isn't necessary anymore and so I patched the assembler to emit LO16 instead of LO14, and that made it work. The patch is attached and I'll try to get it into MacPorts cctools port.

So that way building the G5 optimized TFF using mcpu=970 (without mpowerpc64 or m32) should work and the browser will possibley benefit a little bit from the use of native 64 bit integer instructions and registers.

We can deal with the PPC64 concern in another issue, though I'm perfectly satisfied with the current 32-bit release.

In any case, successfully built 19b1 on the G5 and transplanted it to a vanilla 10.4 system with no MacPorts using a modified version of the install script from AuroraFox. It works. That means this issue is, finally,

Would upgrading to GCC 4.7.3 or 4.8.3 provide any performance advantage?

Maybe, and I do have gcc 4.8 on my build system, but I'm trying not to add churn to builders. I might do this for Fx32+ if we make it that far (Mozilla may require it by then anyway).

If Mozilla requires an current version of the compiler for Fx 32+ then you'll be working w/ GCC 4.9.x. I was reading since the return of IBM to LLVM, they have updated Altivec support. Out of curiosity, you couldn't use LLVM 3.4?

re: LLVM on Mac OS X 10.4/ppc: I'm still actively working on the powerpc-darwin8 port of LLVM/clang/libc++. Recently I gained support from an overseas collaborator, so we have some momentum going again. Basic mach-o/ PPC codegen has been working on some exception-free C++ workloads at -O0, and known issues include libunwind compatibility (patch in testing), and undiagnosed codegen bugs. Self-hosting chokes in stage-2 currently.

You can follow my testing and progress here: http://www.csl.cornell.edu/~fang/sw/llvm/ (I am still looking for more collaborators and testers!)

Heikki's instructions for a cross-building 10.5 gcc with 10.4-compatible libraries:

1. REMOVE MacPorts from PATH. Otherwise some includes will be pulled from there and the cross compiler won't build.

2. build gmp, mpfr, mpc 461 cd gmp-5.1.3 462 ./configure --prefix=/Users/xyz/host/ --target=powerpc-apple-darwin9 --host=powerpc-apple-darwin9 --build=powerpc-apple-darwin9 CC=gcc-4.2 CXX=g++-4.2 CFLAGS="-O2 -g -fno-common" --disable-shared 463 make -j4 464 make check 465 make install

   468 cd mpfr-3.1.2 469 ./configure --prefix=/Users/xyz/host/ --target=powerpc-apple-darwin9 --host=powerpc-apple-darwin9 --build=powerpc-apple-darwin9 CC=gcc-4.2 CXX=g++-4.2 CFLAGS="-O2 -g -fno-common" --with-gmp=/Users/xyz/host --disable-shared 470 make -j4 471 make check 472 make install

   475 cd mpc-1.0.2 476 ./configure --prefix=/Users/xyz/host/ --target=powerpc-apple-darwin9 --host=powerpc-apple-darwin9 --build=powerpc-apple-darwin9 CC=gcc-4.2 CXX=g++-4.2 CFLAGS="-O2 -g -fno-common" --with-gmp=/Users/xyz/host --with-mpfr=/Users/xyz/host --disable-shared 477 make -j4 478 make check 479 make install

3. create bootstrap compiler 486 ../gcc-4.6.4/configure --prefix=/Users/xyz/compilers/gcc-4.6 --target=powerpc-apple-darwin9 --host=powerpc-apple-darwin9 --build=powerpc-apple-darwin9 --enable-version-specific-runtime-libs --with-libiconv-prefix=/usr --with-gmp=/Users/xyz/host --with-mpfr=/Users/xyz/host --with-mpc=/Users/xyz/host --enable-checking=release --enable-languages=c,c++,objc,obj-c++ CC=gcc-4.2 CXX=g++-4.2 487 time make -j4 bootstrap 488 make install

4. set PATH to include said bootstrap compiler

5. create fake darwin8 binutils 359 ln -s /usr/bin/ar powerpc-apple-darwin8-ar 361 ln -s /usr/bin/as powerpc-apple-darwin8-as 362 ln -s /usr/bin/ld powerpc-apple-darwin8-ld 363 ln -s /usr/bin/lipo powerpc-apple-darwin8-lipo 364 ln -s /usr/bin/nm powerpc-apple-darwin8-nm 365 ln -s /usr/bin/strip powerpc-apple-darwin8-strip 366 vim powerpc-apple-darwin8-ranlib

   !/bin/sh

exec /usr/bin/ranlib ${@} exit 1 367 chmod a+x powerpc-apple-darwin8-ranlib

5. set PATH to include the fake binutils

6. create the cross compiler for darwin8 493 ../gcc-4.6.4/configure --prefix=/Users/xyz/compilers/gcc-4.6-darwin8 --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin9 --build=powerpc-apple-darwin9 --enable-version-specific-runtime-libs --with-libiconv-prefix=/usr --with-gmp=/Users/xyz/host --with-mpfr=/Users/xyz/host --with-mpc=/Users/xyz/host --enable-checking=release --with-sysroot=/Developer/SDKs/MacOSX10.4u.sdk --with-dwarf2 --enable-languages=c,c++,objc,obj-c++ 494 gcc -v 495 make -j4 496 make install

7. Before compiling TFF, I set the fake binutils to point to the macports ones and re-enabled macports in PATH.