This bit of code: http://mxr.mozilla.org/mozilla-central/source/configure.in#2037 occurs before: http://mxr.mozilla.org/mozilla-central/source/configure.in#2543 which means that we're always checking for --gc-sections with debug options, even in configurations that might have requested debugging information to be turned off. I don't know whether this affects any release builds right now (Linux 64-bit seems to be OK; I couldn't locate the configuration bits in the Android build logs; I didn't check B2G). But it certainly seems like the sort of thing that could unexpectedly blow up and it can adversely affect compiler comparisons.
FWIW, this is affecting mobile size, as at least the vtables for nsI* base classes are not being GC'd. There may also be unused functions that are present in the final binary. Kats was noticing a big jump in apk size on #mobile this morning; I don't think this is entirely responsible for the size changes, but it's definitely a portion of them. This bug also affects the builds we are doing with GCC 4.7 nowadays.
We build with -g by default, and all our onchange/nightly/release builds are built with it, since we need to dump symbols for crash reporting. (We strip during packaging).
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #2) > We build with -g by default, and all our onchange/nightly/release builds are > built with it, since we need to dump symbols for crash reporting. (We strip > during packaging). The problem is: - The test for gc-sections happens before we get MOZ_DEBUG_FLAGS from configure command line argument parsing. - We set MOZ_DEBUG_FLAGS to -g on *some* platforms before doing the gc-sections test, but not on android. Thus the test doesn't run when should, and we don't enable gc-sections as a consequence. - Other than disabling debug, one can also set their own flags (like passing -gdwarf4), and the test would still run with -g on those platforms where we pre-set to that value, which is not what should happen. BTW, 5 months later, the mxr links are useless.