search for: resolvex86_64reloc

...align-remote.ll LLVM :: ExecutionEngine/MCJIT/test-fp-no-external-funcs-remote.ll LLVM :: ExecutionEngine/MCJIT/test-global-init-nonzero-remote.ll All of them fail 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&...

...al-funcs-remote.ll**** > > LLVM :: ExecutionEngine/MCJIT/test-global-init-nonzero-remote.ll**** > > ** ** > > All of them fail 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 > allocat...

Hi, Attempting to use LLVM in jitting mode for AMD64, we met a problem. When the jitted routine needs a big stack frame (> 1 page), the system attempts to call __chkstk to probe the stack. This attempt results in assertion in RuntimeDyldELF::resolveX86_64Relocation(), case ELF::R_X86_64_PC32, because the RealOffset does not fit in 32 bits. Same happens with __alloca (when IRBuilder::CreateAlloca appears in a conditional block). Perhaps the issue can be fixed by using indirect call via 64-bit register or replicating service routines inside jitted block....

...align-remote.ll LLVM :: ExecutionEngine/MCJIT/test-fp-no-external-funcs-remote.ll LLVM :: ExecutionEngine/MCJIT/test-global-init-nonzero-remote.ll All of them fail 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&...

...al-funcs-remote.ll**** > > LLVM :: ExecutionEngine/MCJIT/test-global-init-nonzero-remote.ll**** > > **** > > All of them fail 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 > allocat...

...d that certain parts of LLVM (RuntimeDyld, JIT) use unaligned memory accesses to load/store pointers or just 32- or 64-bit integers. Technically, this is undefined behavior, and UBSan reports errors when this happens. Even if we believe we're running some x86-specific code (e.g. RuntimeDyldELF::resolveX86_64Relocation) what matters for unaligned acceses in source code is the host architecture, not the target one. What do you think of adding T unaligned_load(const void *addr) void unaligned_store(void *addr, T value); to support headers? We can then provide the default memcpy implementations of these...

...align-remote.ll LLVM :: ExecutionEngine/MCJIT/test-fp-no-external-funcs-remote.ll LLVM :: ExecutionEngine/MCJIT/test-global-init-nonzero-remote.ll All of them fail 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&...

...align-remote.ll LLVM :: ExecutionEngine/MCJIT/test-fp-no-external-funcs-remote.ll LLVM :: ExecutionEngine/MCJIT/test-global-init-nonzero-remote.ll All of them fail 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&...

...ev/null -- Exit Code: 134 Command Output (stderr): -- assertion "RealOffset <= INT32_MAX && RealOffset >= INT32_MIN" failed: file "/cygdrive/z/dev/llvm/x64/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp", line 308, function: void llvm::RuntimeDyldELF::resolveX86_64Relocation(const llvm::SectionEntry&, uint64_t, uint64_t, uint32_t, int64_t, uint64_t) Stack dump: 0. Program arguments: /cygdrive/z/dev/llvm/x64/static/Release+Asserts/bin/lli -use-mcjit -mtriple=x86_64-unknown-cygwin-elf /cygdrive/z/dev/llvm/x64/llvm/test/ExecutionEngine/MCJIT/test-setcond...

...set of functions it attempts to JIT something at least. I run into a segfault, valgrind reports the following: ==27130== Process terminating with default action of signal 11 (SIGSEGV) ==27130== Bad permissions for mapped region at address 0xEAF02F7 ==27130== at 0xEAF031F: llvm::RuntimeDyldELF::resolveX86_64Relocation(llvm::SectionEntry const&, unsigned long, unsigned long, unsigned int, long, unsigned long) (RuntimeDyldELF.cpp:213) ==27130== by 0xEAF260F: llvm::RuntimeDyldELF::resolveRelocation(llvm::SectionEntry const&, unsigned long, unsigned long, unsigned int, long, unsigned long) (RuntimeDy...

...: > -- > assertion "RealOffset <= INT32_MAX && RealOffset >= INT32_MIN" > failed: file > "/cygdrive/z/dev/llvm/x64/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp", > line 308, function: void > llvm::RuntimeDyldELF::resolveX86_64Relocation(const > llvm::SectionEntry&, uint64_t, uint64_t, uint32_t, int64_t, uint64_t) > Stack dump: > 0. Program arguments: > /cygdrive/z/dev/llvm/x64/static/Release+Asserts/bin/lli -use-mcjit > -mtriple=x86_64-unknown-cygwin-elf > /cygdrive/z/dev/llv...

...to JIT something at least. > I run into a segfault, valgrind reports the following: > > ==27130== Process terminating with default action of signal 11 (SIGSEGV) > ==27130== Bad permissions for mapped region at address 0xEAF02F7 > ==27130== at 0xEAF031F: > llvm::RuntimeDyldELF::resolveX86_64Relocation(llvm::SectionEntry const&, > unsigned long, unsigned long, unsigned int, long, unsigned long) > (RuntimeDyldELF.cpp:213) > ==27130== by 0xEAF260F: > llvm::RuntimeDyldELF::resolveRelocation(llvm::SectionEntry const&, unsigned > long, unsigned long, unsigned int, long,...

...p;view=diff ============================================================================== --- llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp (original) +++ llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp Mon Aug 19 18:27:43 2013 @@ -202,7 +202,8 @@ void RuntimeDyldELF::resolveX86_64Reloca uint64_t Offset, uint64_t Value, uint32_t Type, - int64_t Addend) { + in...

Without the MSP_32BIT part, I consistently hit this assertion: Assertion failed: ((Type == ELF::R_X86_64_32 && (Value <= UINT32_MAX)) || (Type == ELF::R_X86_64_32S && ((int64_t)Value <= INT32_MAX && (int64_t)Value >= INT32_MIN))), function resolveX86_64Relocation, file ../lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp, line 222. David On 9 May 2013, at 13:58, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > Can you try it without the MAP_32BIT part? It won't be as reliable, but if the memory addresses it is asking f...

Can you try it without the MAP_32BIT part? It won't be as reliable, but if the memory addresses it is asking for are available it could work. I agree that there are good reasons not to lock in on a single memory address, but I'm curious as to what other obstacles might be lurking behind the ones we know about. If the patch works when memory is loaded below 2GB then it would be possible

...; > Without the MSP_32BIT part, I consistently hit this assertion: > > Assertion failed: ((Type == ELF::R_X86_64_32 && (Value <= UINT32_MAX)) || > (Type == ELF::R_X86_64_32S && ((int64_t)Value <= INT32_MAX && > (int64_t)Value >= INT32_MIN))), function resolveX86_64Relocation, file > ../lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp, line 222. > > David > > On 9 May 2013, at 13:58, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > > > Can you try it without the MAP_32BIT part? It won't be as reliable, but > i...

...(an experimental patch) Without the MSP_32BIT part, I consistently hit this assertion: Assertion failed: ((Type == ELF::R_X86_64_32 && (Value <= UINT32_MAX)) || (Type == ELF::R_X86_64_32S && ((int64_t)Value <= INT32_MAX && (int64_t)Value >= INT32_MIN))), function resolveX86_64Relocation, file ../lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp, line 222. David On 9 May 2013, at 13:58, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > Can you try it without the MAP_32BIT part? It won't be as reliable, but if the memory addresses it is asking f...

...lem is after creating the object file. When I link the object file with ld I get an executable, which is working right. After changing the clang and llvm libraries from the package control version (.deb) to a own compiled version with debug options, I get an assert() fault. In void RuntimeDyldELF::resolveX86_64Relocation() at the case ELF::R_X86_64_PC32 this will throw an assert. You can find the code in the file llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp . I don't know exactly, what this function do but after first research, I think it has something to do with the linking. Maybe You know more...