similar to: [LLVMdev] [LLVMDev][3.5]: assertion failed in RuntimeDyldELF.cpp

Hi Lang Le 24/07/2014 18:17, Lang Hames a écrit : > Hi Francis, > > It is possible to XFAIL a regression test (grep for XFAIL in the > llvm/test directory for examples), however that's discouraged. The > fact that this test is failing indicates that part of the JIT > infrastructure is broken on W7/X86_64/Cygwin. > > How long have you been building LLVM in this

Hi! I'm trying to run LLVM test suite under AddressSanitizer and get test failures in: 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 All of them fail with assertion: lli:

Hi Andrew, Looks like RecordingMemoryManager in lli just calls malloc() and it would be strange to make assumptions (or enforce) that the difference between two returned pointers in 64-bit virtual address space will be fit into 32 bits. Can we do smth similar to what Adhemerval proposed (see the special case in processRelocationRef for ELF::R_PPC64_REL24 relocations)? On Tue, Jan 29, 2013 at

Hi Alexey, 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

On Wed, Jan 30, 2013 at 8:34 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > Yes, at some point we definitely should introduce stubs as a last resort > for x86-64 relocations when the sections are too far apart, but I’d like to > avoid it whenever possible.**** > > ** ** > > What I meant in my previous message was that I’d have > RecordingMemoryManager use

Yes, at some point we definitely should introduce stubs as a last resort for x86-64 relocations when the sections are too far apart, but I'd like to avoid it whenever possible. What I meant in my previous message was that I'd have RecordingMemoryManager use something other than malloc (such as the memory API used by SectionMemoryManager) to keep section near one another. -Andy From:

It's probably best to open a bug. -Andy From: Alexey Samsonov [mailto:samsonov at google.com] Sent: Thursday, January 31, 2013 12:27 AM To: Kaylor, Andrew Cc: LLVM Developers Mailing List Subject: Re: Assertions in RuntimeDyldELF in ExecutionEngine/MCJIT tests On Wed, Jan 30, 2013 at 8:34 PM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote:

Hi Lang, Yeah, I remember this case. Basically what’s happening is that there are relocations for ELF on x86 that use a value that is present in the object image as part of the calculation for the final value that goes in the same location. If you ever find yourself applying relocations for a second time (for instance, because the loaded object location is remapped for out-of-proc execution)

Hi, We are seeing sporadic crashes since we migrated to MCJIT on Win64. The same tests pass without issues on Mac64 and Linux64. The issue is this assertion failure in RuntimeDyldELF.c: RealOffset <= INT32_MAX && RealOffset >= INT32_MIN I haven't managed to successfully catch the failure in Visual to try and debug it. Any tips on how to make progress? Oh, and we're on

So it appears that we get about half the crashes with the large code model. The rest are crashing in the same way. It could either mean that large code model still takes that crashing codepath and that the number of crashes only went down by chance, or that in one place in the flow, large code model is not matched to mean ELF::R_X86_64_PC64. I'm digging into this issue further, but any hints

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

On Fri, May 22, 2015 at 4:14 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > This might be related to GOT relocations. I rewrote that part of > RuntimeDyldELFbecause I was seeing this issue. Have you tried trunk? > I didn't notice that you were running 3.5 the first time I read this. Keno's diagnosis is very likely to be correct. You should try trunk if

Hi Dale, I don't think that Keno's rewrite is applicable for a bug fix release. We have, in the last year, moved to having some dot releases for our older releases, but these are definitely bug fix only and low risk as we don't want to break anything new. The release documentation is located here: http://llvm.org/docs/HowToReleaseLLVM.html for future reference. There's no

Hi List, I'm trying to upgrade our llvm-c based compiler from JIT to MCJIT. While trying to do so I encountered several problems. Looks like C API does not have proper functions to intialize LLVM with MCJIT. I ended up wrapping the following functions in my own init routine. LLVMInitializeX86TargetInfo(); LLVMInitializeX86Target(); LLVMInitializeX86TargetMC(); LLVMInitializeX86AsmPrinter();

I managed to make it work by cloning code from lli and making my own cpp wrapper. 2013/9/22 Konstantin Olkhovskiy <lupus at oxnull.net> > Hi List, > > I'm trying to upgrade our llvm-c based compiler from JIT to MCJIT. > While trying to do so I encountered several problems. Looks like C > API does not have proper functions to intialize LLVM with MCJIT. > I ended up

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

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.2 10.1" <mesa-stable at lists.freedesktop.org> --- Found this while tracking a regression on nvc0 for my patch which fixes ir_unop_any to emit or's instead of dp3's. (That patch is fine, this code was always broken.) src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 3 ++- 1 file changed, 2

On 09.05.2015 07:35, Ilia Mirkin wrote: > This has started to happen more now that the backend is producing > KILL_IF more often. > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- > .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 29 ++++++++++++++++++++++ > .../nouveau/codegen/nv50_ir_target_nv50.cpp | 2 ++ > 2 files changed, 31

Hello everyone, As part of my quest to add TLS relocation support to MCJIT, I've been taking a closer look at the GOT implementation in RuntimeDyldELF and I believe that is not valid as currently implemented. In particular, I am wondering about the multiple GOT handling support introduced in r192020. If I understand correctly this can make code reuse the GOT table entry in a different object