[LLVMbugs] [Bug 15130] New: Assertions in RuntimeDyldELF in ExecutionEngine/MCJIT tests

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=15130

             Bug #: 15130
           Summary: Assertions in RuntimeDyldELF in ExecutionEngine/MCJIT
                    tests
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: samsonov at google.com
                CC: andrew.kaylor at intel.com, eugeni.stepanov at gmail.com,
                    kcc at google.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The following tests from LLVM test suite fails under AddressSanitizer:
    LLVM :: ExecutionEngine/MCJIT/simpletest-remote.ll
    LLVM :: ExecutionEngine/MCJIT/test-data-align-remote.ll
    LLVM :: ExecutionEngine/MCJIT/test-fp-no-external-funcs-remote.ll
    LLVM :: ExecutionEngine/MCJIT/test-global-init-nonzero-remote.ll

with assertion: lli:
/usr/local/google/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:230:
void llvm::RuntimeDyldELF::resolveX86_64Relocation(const llvm::SectionEntry &,
uint64_t, uint64_t, uint32_t, int64_t): Assertion `RealOffset <= (2147483647)
&& RealOffset >= (-2147483647-1)' failed.

The reason is that AddressSanitizer replaces system malloc with its own
allocator, which allocates memory at "unusual" parts of heap and the difference
between pointers can be significant (and doesn't fit in 32 bytes).

====
Repro:
$ cd llvm_asan_build
$ export CC=clang
$ export CXX=clang++
$ cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON \
  -DCMAKE_C_FLAGS="-fno-omit-frame-pointer -g -fsanitize=address" \
  -DCMAKE_CXX_FLAGS="-fno-omit-frame-pointer -g -fsanitize=address" \
  /path/to/llvm/checkout
$ make check-llvm -j8

=====
Comment by Andrew Kaylor:

I think the most likely way to resolve this is to have the
RecordingMemoryManager do something more complex to manage its allocations in
such a way as to guarantee that they are all within proximity of one another. 
The code that is asserting is handling a relocation where code was generated to
use a 32-bit relative offset in 64-bit code.  If the two sections involved
really are more than a 32-bit offset apart then the generated code will not
work.

Alternatively, we could have MCJIT use whatever code generation option will
prevent 32-bit relative relocations from being generated in the first place. 
That would probably be preferable, but I haven’t had success trying to do that
in limited efforts up to now.
=====

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.