964641 - Linux64 PGO+non-unified fails to link editline and AsmJSModule

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Phil Ringnalda (:philor)]

You've got one week until we merge to aurora, and start doing PGO-only, non-unified-only builds there, and Linux64 opt with be permared. Go!

https://tbpl.mozilla.org/php/getParsedLog.php?id=33664533&tree=Try is central as though it had been merged to aurora, including the version number bump that turns off unified sources, and building PGO.

./editline/editline.i_o: In function `TTYspecial':
/builds/slave/try-l64-0000000000000000000000/build/js/src/editline/editline.c:874: relocation truncated to fit: R_X86_64_PC32 against symbol `rl_erase' defined in COMMON section in ../editline/editline.i_o
/builds/slave/try-l64-0000000000000000000000/build/js/src/editline/editline.c:876: relocation truncated to fit: R_X86_64_PC32 against symbol `rl_kill' defined in COMMON section in ../editline/editline.i_o
/builds/slave/try-l64-0000000000000000000000/build/js/src/editline/editline.c:884: relocation truncated to fit: R_X86_64_PC32 against symbol `rl_eof' defined in COMMON section in ../editline/editline.i_o
/builds/slave/try-l64-0000000000000000000000/build/js/src/editline/editline.c:886: relocation truncated to fit: R_X86_64_PC32 against symbol `rl_intr' defined in COMMON section in ../editline/editline.i_o
/builds/slave/try-l64-0000000000000000000000/build/js/src/editline/editline.c:890: relocation truncated to fit: R_X86_64_PC32 against symbol `rl_quit' defined in COMMON section in ../editline/editline.i_o
../editline/sysunix.i_o: In function `rl_ttyset':
/builds/slave/try-l64-0000000000000000000000/build/js/src/editline/sysunix.c:44: relocation truncated to fit: R_X86_64_PC32 against symbol `rl_erase' defined in COMMON section in ../editline/editline.i_o
/builds/slave/try-l64-0000000000000000000000/build/js/src/editline/sysunix.c:45: relocation truncated to fit: R_X86_64_PC32 against symbol `rl_kill' defined in COMMON section in ../editline/editline.i_o
/builds/slave/try-l64-0000000000000000000000/build/js/src/editline/sysunix.c:46: relocation truncated to fit: R_X86_64_PC32 against symbol `rl_eof' defined in COMMON section in ../editline/editline.i_o
/builds/slave/try-l64-0000000000000000000000/build/js/src/editline/sysunix.c:47: relocation truncated to fit: R_X86_64_PC32 against symbol `rl_intr' defined in COMMON section in ../editline/editline.i_o
/builds/slave/try-l64-0000000000000000000000/build/js/src/editline/sysunix.c:48: relocation truncated to fit: R_X86_64_PC32 against symbol `rl_quit' defined in COMMON section in ../editline/editline.i_o
../libjs_static.a(AsmJSModule.i_o): In function `JSC::MacroAssemblerX86Common::setSSECheckState()':
/builds/slave/try-l64-0000000000000000000000/build/js/src/../../js/src/assembler/assembler/MacroAssemblerX86Common.h:1405: additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
make[7]: *** [js] Error 1

Comment 1

[Mike Hommey [:glandium]]

And the bisect winner is:

changeset:   164749:ce9500f47c73
user:        Steve Fink <[e-mail]>
date:        Wed Jan 22 11:52:44 2014 -0800
summary:     Bug 960342 - Add a RootedGeneric general class, r=terrence

Comment 2

[Mike Hommey [:glandium]]

And apparently, what triggers it is adding the RootedGeneric template, even unused.
Note that editline is not really involved in this. It just happens to be collateral damage from something happening due to that change and making the linker place some code and some data too far apart from each other.

Comment 3

[Mike Hommey [:glandium]]

FWIW, with -Wl,--verbose, there are 55534 "relocation truncated to fit" messages. All of them are about text relocations to COMMON or bss data.

Comment 4

[Mike Hommey [:glandium]]

Attachment: Don't PGO js/src/vm/Value.cpp

When building Value.cpp with optimization and -fprofile-generate with gcc 4.7,
it creates a 32GB unused bss symbol. When linking, 32 bits relocations that
cross that 32GB gap (typically, text relocations for accesses to bss variables)
can't be fulfilled, since 32GB is too big, leading to a build failure.

Fortunately, Value.cpp doesn't contain actual code, so not PGOing it to work
around this bug won't have performance impact.

Comment 5

[Mike Hommey [:glandium]]

Filed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59973.

Comment 6

[Phil Ringnalda (:philor)]

Happy try pushes of central-plus-that-patch-as-aurora in https://tbpl.mozilla.org/?tree=Try&rev=1db65761c661 and https://tbpl.mozilla.org/?tree=Try&rev=c14116376fca

Comment 7

[Benjamin Kerensa [:bkerensa]]

I think it will be important for us to keep a watch on this so there is no impact to our Linux users. Tracking this for now.

Comment 8

[Phil Ringnalda (:philor)]

Well, the thing that will be most impactful on our Linux users is that either this lands before Monday's uplift to aurora, or aurora's Linux64 builds will burn, and aurora will remain closed and unable to build until this lands there.

Comment 9

[Mike Hommey [:glandium]]

Actually, we already have a patched gcc in production, due to a combination of bug 938510 and bug 965122 (that one needs a landing on m-c, too, to make the in-tree gcc build script match the gcc we now use). So it's not really a problem anymore.