search

Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

Infinite loop in resolveRelocationList on AArch64 #23429

Open Quuxplusone opened 9 years ago

Quuxplusone commented 9 years ago
Bugzilla Link PR23430
Status NEW
Importance P normal
Reported by Csaba Osztrogonác (oszi@inf.u-szeged.hu)
Reported on 2015-05-06 04:43:07 -0700
Last modified on 2015-05-06 11:45:24 -0700
Version 3.6
Hardware PC All
CC lhames@gmail.com, llvm-bugs@lists.llvm.org, rwindz0@gmail.com, tim.northover@arm.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also 
WebKit's JavaScript engine uses LLVM to optimize/generate native code if FTL
JIT is enabled. But it stucks in an infinite loop inside LLVM on AArch64.
It works fine with LLVM 3.5, but got this infinite loop with 3.6.

How to reproduce the bug (on a Juno board on Ubuntu 14.04):
- clone WebKit: git clone git://git.webkit.org/WebKit.git WebKit
- apply a patch to use LLVM 3.6 (not 3.5 which is the default on ARM).
  ( https://bugs.webkit.org/show_bug.cgi?id=143821 )
- install dependencies: sudo Tools/efl/install-dependencies
- build other dependencies: Tools/Scripts/update-webkitefl-libs
- build LLVM 3.6: Tools/Scripts/update-webkitefl-libs llvm-3.6
- build the JavaScriptCore: Tools/Scripts/build-jsc --efl --ftl-jit
- execute the tests: Tools/Scripts/run-javascriptcore-tests --efl --ftl-jit
(It can be reproduced on each test, I'll send a simple command soon.)

gdb backtrace:
#0  0x000000200718fc08 in
llvm::RuntimeDyldELF::resolveAArch64Relocation(llvm::SectionEntry const&,
unsigned long, unsigned long, unsigned int, long) () from /home/oszi/jsc-
tests/jsc-stress-results/.vm/JavaScriptCore.framework/Resources/libllvmForJSC.so
#1  0x0000002007184bb4 in
llvm::RuntimeDyldImpl::resolveRelocationList(llvm::SmallVector<llvm::RelocationEntry,
64u> const&, unsigned long)
    () from /home/oszi/jsc-tests/jsc-stress-results/.vm/JavaScriptCore.framework/Resources/libllvmForJSC.so
#2  0x0000002007184bb4 in
llvm::RuntimeDyldImpl::resolveRelocationList(llvm::SmallVector<llvm::RelocationEntry,
64u> const&, unsigned long)
    () from /home/oszi/jsc-tests/jsc-stress-results/.vm/JavaScriptCore.framework/Resources/libllvmForJSC.so
...
#XXXXX (endless stack trace)
Quuxplusone commented 9 years ago 
I managed to get better bakctrace with debug LLVM:

(gdb) bt
#0  0x0000007f768f3c08 in llvm::RuntimeDyldELF::resolveAArch64Relocation
(this=<optimized out>, Section=..., Offset=28, Value=547548787360, Type=260,
    Addend=0) at RuntimeDyldELF.cpp:333
#1  0x0000007f768e8bb4 in llvm::RuntimeDyldImpl::resolveRelocationList
(this=this@entry=0x19b75c70, Relocs=..., Value=547548787360) at
RuntimeDyld.cpp:707
#2  0x0000007f768ecb6c in llvm::RuntimeDyldImpl::resolveRelocations
(this=0x19b75c70) at RuntimeDyld.cpp:95
#3  0x0000007f768ecc48 in llvm::RuntimeDyld::resolveRelocations
(this=this@entry=0x19b50390) at RuntimeDyld.cpp:837
#4  0x0000007f768d9540 in llvm::MCJIT::finalizeLoadedModules
(this=this@entry=0x19b502b0) at MCJIT.cpp:219
#5  0x0000007f768d98b0 in llvm::MCJIT::finalizeObject (this=0x19b502b0) at
MCJIT.cpp:243
#6  0x0000007f768e4f28 in LLVMGetPointerToGlobal (EE=0x19b502b0,
Global=<optimized out>) at ExecutionEngineBindings.cpp:326
#7  0x0000007f8055ebcc in JSC::FTL::compile(JSC::FTL::State&,
JSC::DFG::Safepoint::Result&) ()
   from /home/oszi/jsc-tests/jsc-stress-results/.vm/JavaScriptCore.framework/Resources/libjavascriptcore_efl.so.1
#8  0x0000007f801f0a24 in
JSC::DFG::Plan::compileInThreadImpl(JSC::DFG::LongLivedState&) ()
   from /home/oszi/jsc-tests/jsc-stress-results/.vm/JavaScriptCore.framework/Resources/libjavascriptcore_efl.so.1
#9  0x0000007f801f0bc0 in
JSC::DFG::Plan::compileInThread(JSC::DFG::LongLivedState&,
JSC::DFG::ThreadData*) ()
   from /home/oszi/jsc-tests/jsc-stress-results/.vm/JavaScriptCore.framework/Resources/libjavascriptcore_efl.so.1
#10 0x0000007f8016db84 in JSC::DFG::compile(JSC::VM&, JSC::CodeBlock*,
JSC::CodeBlock*, JSC::DFG::CompilationMode, unsigned int,
JSC::Operands<JSC::JSValue, JSC::OperandValueTraits<JSC::JSValue> > const&,
WTF::PassRefPtr<JSC::DeferredCompilationCallback>) ()
   from /home/oszi/jsc-tests/jsc-stress-results/.vm/JavaScriptCore.framework/Resources/libjavascriptcore_efl.so.1
#11 0x0000007f801d5e28 in triggerFTLReplacementCompile ()
   from /home/oszi/jsc-tests/jsc-stress-results/.vm/JavaScriptCore.framework/Resources/libjavascriptcore_efl.so.1
#12 0x0000007f801d605c in triggerTierUpNow () from /home/oszi/jsc-tests/jsc-
stress-results/.vm/JavaScriptCore.framework/Resources/libjavascriptcore_efl.so.1
#13 0x0000007f7c736f1c in ?? ()
#14 0x0000007f7a0653b0 in ?? ()

------

=> 0x0000007f768f3c08 <+24>:    adrp    x1, 0x7f76f3c000
   0x0000007f768f3c0c <+28>:    add     x1, x1, #0x330
   0x0000007f768f3c10 <+32>:    ldrb    w7, [x1,w4,uxtw]
   0x0000007f768f3c14 <+36>:    adr     x8, 0x7f768f3c20 <llvm::RuntimeDyldELF::resolveAArch64Relocation(llvm::SectionEntry const&, unsigned long, unsigned long, unsigned int, long)+48>
   0x0000007f768f3c18 <+40>:    add     x7, x8, w7, sxtb #2
   0x0000007f768f3c1c <+44>:    br      x7

------

It's strange ... I tried to step with si in gdb
and br x7 always jump back to to adrp instruction,
but there isn't any loop in resolveAArch64Relocation(),
so it is very unlikely that it is an LLVM bug, but a
compiler (GCC) bug or an ARM hardware bug.