similar to: [LLVMdev] [MCJIT] Multiple GOT handling in RuntimeDyldELF

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)

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! 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 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 LLVMDev list I am building LLVM from the SVN trunk at 213638 on a W7/X86_64/Cygwin system and running make check leads to a series of failed assertions like ******************** FAIL: LLVM :: ExecutionEngine/MCJIT/test-setcond-fp.ll (6185 of 11245) ******************** TEST 'LLVM :: ExecutionEngine/MCJIT/test-setcond-fp.ll' FAILED ******************** Script: --

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

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

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

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:

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

Hi Keno, The part that scares me a bit is > and then adjust the other methods to not > bail out two quickly when encountering a weak symbol. I would very much appreciate if you could implement this; I don't have enough knowledge of the MCJIT nor llvm CodeGen internals... I will happily try it out and provide you with feedback, though! :-) Thank you *so* much for your fast reaction!

Hi Keno, Could you give a short high-level overview of the way Julia works now with MCJIT instead the JIT: What I gather so far... * Compiled IR functions are emitted to a shadow module. * Any used function is cloned into its own new module and the module is added to MCJIT. * Called functions or globalvars are only declared in that module. * Modules are never removed meaning "old"

Hi Keno, I am talking about runtime. The performance of the generated machine code. Not the time it takes to lower the IR to machine code. We typically only JIT once (taking a few secs) and then run the generated machine code for hours. So the JIT time (IR -> machine code) doesn't impact us. Cheers Morten On 05/02/16 15:58, Keno Fischer wrote: > Actually, reading over all of this

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

Hi folks, Three MCJIT tests are failing on both our buildbots (check-all and self-host) and I'm not sure what's the best way to fix it. Some test passes, some not on { A9, A15 } x { Ubuntu 12.10, Ubuntu 12.04 }, the error is: lli: /home/user/devel/llvm/src/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:307: void llvm::RuntimeDyldELF::resolveARMRelocation(const

On 22 May 2013 12:30, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > To clarify, MCJIT currently has no GOT support whatsoever for ELF with x86-64 and ARM (and probably others). No, I added a bare minimal to get EH working... > My experimental patch was meant as an attempt to get TLS working with static relocation model and small code model. It's the combination of these