[Webkit-unassigned] [Bug 137434] New: [JSC] Segfault on ARM64 with gcc in elf_dynamic_do_Rela

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=137434

           Summary: [JSC] Segfault on ARM64 with gcc in
                    elf_dynamic_do_Rela
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: akiss at inf.u-szeged.hu
                CC: oliver at apple.com, dbates at webkit.org,
                    msaboff at apple.com, fpizlo at apple.com


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).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.