similar to: [LLVMdev] [RFC] Adding functions for unaligned load/store to Support for JIT/RuntimeDyld

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 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();

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

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

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

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

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

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

Hello LLVMDevs, I have written a .cpp file in lib/Target/(some arch)/ and i want to use one of its function in a file in lib/ExecutionEngine/RuntimeDyld/. So is there any specific way to do that. This may be a general question for any one who writes a .cpp file in Target/(any arch)/ and tries to use it somewhere in ExecitionEngine/RuntimeDyld/. Please guide. Thanks, Siddharth -------------- next

Hi All Is there any technical reason why we can’t or shouldn’t have RuntimeDyld be able to enumerate all symbols in the dyld? I know elf, mach-o apis have this capability, and I’m reasonably sure coff has support for it as well.

Hi, I believe I came across a bug in RuntimeDyld. I have the following piece of C code (attached as rtdyldbug.c): double numbers[5] = {33, 34, 35, 36, 37}; void foo(double val, double other[]) { other[2] += val * numbers[4]; } I adapted llvm-rtdyld.cpp to load the .o file of the code above, get a pointer to foo, and invoke it (whole thing is attached as myrtdyld.cpp): typedef

Hi Lang, Thanks for your help at the Hackers Lab. Fixing the problems we identified in RuntimeDyldMachOARM.h improves the MachO_ARM_PIC_relocations.s test quite a lot but there's one failed check that's proving a bit stubborn: Expression '*{4}(stub_addr(foo.o, __text, baz)) = 0xe51ff004' is false: 0x4f01fe5 != 0xe51ff004 I'm struggling to find the cause of

+llvm-commits (correct list) On Tue, Sep 22, 2015 at 12:32 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: > Could you describe the build failures you see after applying this patch? > I'll let Chris judge if adding -Wl,-syslibroot makes sense for iossim, or > that problem should be solved differently. > > On Tue, Sep 22, 2015 at 9:37 AM, Alex Wang via llvm-dev <

Hi David, I believe that assertion indicates that something didn't get loaded into the lower 2GB of address space. That is, the memory manager isn't allocating memory in that range. I'm sure there must be a way to allocate memory in that range on FreeBSD. The system loader has to do it, right? I just don't know what makes it happen. -Andy -----Original Message----- From: Dr

Hi! Implementing the Memory::allocateMappedMemory() function on z/OS, I see a failure in the AArch64 COFF test case. The test case has 3 sections. For each section, Memory::allocateMappedMemory() is called to reserve memory. If the distance between the pointers gets too large, then the test case fails. It can be reliable produced with a distance of 1MB between the pointers. An easy way to