Bug 137434

When building a debug jsc for ARM64/Linux/GTK with gcc (4.8.3, as shipped with Ubuntu 14.04.1), the resulting binary is completely unusable. The execution of the app stops with segfault very early, as revealed by gdb: Program received signal SIGSEGV, Segmentation fault. elf_dynamic_do_Rela (skip_ifunc=<optimized out>, lazy=0, nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out>, map=0x7fb7ffb770) at do-rel.h:112 112 do-rel.h: No such file or directory. This is still the dynamic linking phase of jsc to its dependencies. After digging deeper, it turned out that some dynamic relocations in libjavascriptcoregtk.so cause the problem. Further analysis revealed that some symbols in the object file compiled from jit/ThunkGenerators.cpp are in the wrong section, in .text instead of .data. The following is an excerpt from the output of objdump run on ThunkGenerators.cpp.o, i.e., from the symbol table: 0000000000000000 l O .data.rel 0000000000000008 _ZN3JSCL14jsRoundWrapperE 0000000000001e68 l O .text 0000000000000008 _ZN3JSCL10expWrapperE 0000000000001e78 l O .text 0000000000000008 _ZN3JSCL10logWrapperE 0000000000001e88 l O .text 0000000000000008 _ZN3JSCL12floorWrapperE 0000000000001e98 l O .text 0000000000000008 _ZN3JSCL11ceilWrapperE The following lines are the relevant part of the source code: #elif CPU(ARM64) #define defineUnaryDoubleOpWrapper(function) \ asm( \ ".text\n" \ ".align 2\n" \ ".globl " SYMBOL_STRING(function##Thunk) "\n" \ HIDE_SYMBOL(function##Thunk) "\n" \ SYMBOL_STRING(function##Thunk) ":" "\n" \ "b " GLOBAL_REFERENCE(function) "\n" \ ); \ extern "C" { \ MathThunkCallingConvention function##Thunk(MathThunkCallingConvention); \ } \ static MathThunk UnaryDoubleOpWrapper(function) = &function##Thunk; #else #define defineUnaryDoubleOpWrapper(function) \ static MathThunk UnaryDoubleOpWrapper(function) = 0 #endif defineUnaryDoubleOpWrapper(jsRound); defineUnaryDoubleOpWrapper(exp); defineUnaryDoubleOpWrapper(log); defineUnaryDoubleOpWrapper(floor); defineUnaryDoubleOpWrapper(ceil); And now comes the revelation: this bug has nothing to do with the GTK port but it's a bug in gcc. The following minimized example also exhibits the problem: #include <math.h> #define ASM_AND_VAR(fn) \ asm(".text"); \ static double (*var##fn)(double) = &fn; ASM_AND_VAR(exp); ASM_AND_VAR(log); The assembly output is: .cpu cortex-a53+fp+simd .file "asmtext.cpp" #APP .text #NO_APP .data .align 3 .type _ZL6varexp, %object .size _ZL6varexp, 8 _ZL6varexp: .xword exp #APP .text #NO_APP .align 3 .type _ZL6varlog, %object .size _ZL6varlog, 8 _ZL6varlog: .xword log After the second asm(".text"); (or rather: before the second static double variable) gcc does not insert a .data assembler directive. So, it seems GTK is only suffering because it puts the JS engine into a shared lib instead of linking it statically (the static linker gets over this issue).