similar to: LLVM JIT 3.9 vs 6.0: How to emitAndFinalize multiple modules correctly?

Hi all, hi Lang It's a little late to report issues for release_50, but I just found that thing while porting my JitFromScratch examples to 5.0. This is a really nifty detail, but (if I'm not mistaken) the function signature of RTDyldObjectLinkingLayer::NotifyLoadedFtor is incorrect: $ grep -h -r -A 1 "using NotifyLoadedFtor"

Hi Bjoern, CCing cfg-dev (since that's where the conversation started) and llvm-dev (since it's relevant there). Do you know if there is a way to obtain the fully resolved obj-code? I > wanted to load the functions into a shared memory, but how? The only thing > I receive is a function pointer, but I don't know how large the function > 'behind' is. Even a call to

Hi, I wrote a compiler that generate IR code and run it on the JIT, and there randomly crashed due to "corrupted size vs. prev_size" depends on the IR code generated from the source code. Here's how I created the JIT: llvm::InitializeNativeTarget(); llvm::InitializeNativeTargetAsmPrinter(); llvm::InitializeNativeTargetAsmParser(); // create jit llvm::orc::ExecutionSession

Hi Lang, thank You very much. I've used Your code and the creating of the object file works. I think the problem 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

Hi Christian Your use case seems to have similar requirements as remote JITing in ORC. So far I haven't used that part myself and I am sure Lang can tell you much more about it. However, this comment on the RemoteObjectClientLayer class sounds promising for your questions (1) and (2): /// Sending relocatable objects to the server (rather than fully relocated /// bits) allows JIT'd code

I tree to compile the LLVM ORC JIT examples. But I'm stuck in some problems I can't solve my own. First at all I compile with C++14 enabled with latest stable LLVM and clang, this means 4.0.1. I get the following error. Do I missed some specific compile option? Compilation looks like this here. |CompilingcontribJIT.cpp PWD:/home/ikuehl/projects-llvm/TurboLisp/domainEngineer

Trying to put together a simple test JIT compiler, using ORC which as I understand it will be the supported API going forward, I noticed that in the first chapter of the updated Kaleidoscope tutorial, there is sample code that starts like this: ExecutionSession ES; RTDyldObjectLinkingLayer ObjectLayer; IRCompileLayer CompileLayer; DataLayout DL; MangleAndInterner Mangle; ThreadSafeContext Ctx;

Hi everyone, hi Lang, I have a question about Orc JIT (and I think LLVM JIT in general). I am jitting some C++ code that calls atexit and registers a function at some address 0xdeadbeef. Everything is fine, but when the host program (the one that JITs C++ code) shuts down, then I see a crash: error: memory read failed for 0xdeadbeef With the following backtrace: * frame #0:

Firstly, apologies if this is not the right place to be asking this question--feel free to point me in the correct direction. I could be doing something wrong here but stackoverflow didn't feel like the correct place for this since there's so little there about LLVM ORC. Basically, I have a reproduction case (below) where if I throw an exception before I call JITSymbol::getAddress()

Hi David, This looks like bad eh-frame data due to a failure to fix up the frame descriptor entries: <debug: adding frame> EHFrameAddr: 0x7feae5827000, EHFrameLoadAddr: 0x00000000e5827000, EHFrameSize: 60 ==64588==ERROR: AddressSanitizer: SEGV on unknown address 0x7feae5827020 (pc 0x7feae886d970 bp 0x000000000001 sp 0x7ffca10e75f8 T0) Eyeballing the code in RuntimeDyldELF (vs

Hi David, Thanks very much for that. I'll continue to dig in as time permits, and I'll update the bug report with my progress once it's filed. Cheers, Lang. On Mon, Apr 17, 2017 at 6:42 PM, David Lurton <dlurton at gmail.com> wrote: > Thanks Lang. I think I'll go the bug creation route. I have an email out > to llvm-admin requesting an account on bugs.llvm.org.

> It's not the job of the Orc engine. I could argue about this, but I won’t :) > Just don't use atexit. The problem is that I run third-party programs. I cannot control them. > On 20. Nov 2017, at 01:04, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, Nov 20, 2017 at 12:22:49AM +0100, Alex Denisov via llvm-dev wrote: >> JIT

Hi David, Sorry to hear. Has anyone followed up with you yet? I've continued to dig in to this in my spare time and I've found the issue. It's a use-after-free, rather than any sort of memory smashing. ORC is currently failing to deregister the EH-frame section when the JIT is torn down (but *is* deallocating the memory for it). Normally that's not disastrous (though it does

I'm trying to use PerfJITEventListener with llvm::orc::LLJITBuilder: 1. perf record -o /tmp/perf.data -- <my_binary_with_event_listener> 2. perf inject -j -v -i /tmp/perf.data -o /tmp/perf.data.jit *jit marker found: ~.debug/jit/llvm-IR-jit-20200417-3c2242/jit-149849.dump* *injecting: ~/.debug/jit/llvm-IR-jit-20200417-3c2242/jit-149849.dump* *write ELF image

Maybe the easiest workaround would be overriding symbol resolution for the function name and redirect it to your own version in static code (and hope it has no bad side effect on your use case). I think when running 3rd party code, the only way to definitely avoid this kind of trouble is to never deallocate any code or data sections. Doug Binks mentioned that too in his cppcast about Runtime

Hi all, I am using LLVM for JIT use-case and compile functions on the fly. I want to "free" the modules after some time and reclaim any memory associated with it. I am using the SimpleORC API <https://llvm.org/docs/tutorial/BuildingAJIT1.html> now. Is there an API to "free" all the memory associated with the module? I use one "compiler" instance (think similar

Dear LLVM-Developers and Vinod Grover, we are trying to extend the cling C++ interpreter (https://github.com/root-project/cling) with CUDA functionality for Nvidia GPUs. I already developed a prototype based on OrcJIT and am seeking for feedback. I am currently a stuck with a runtime issue, on which my interpreter prototype fails to execute kernels with a CUDA runtime error. === How to use the

Refactoring the previous patch ended up creating two deltas. This patch pushes them both together into a single commit.

Agreed, that sounds like the best plan. I'll look into moving LLILC to ORC. Thanks -Joseph From: Russell Hadley Sent: Friday, May 29, 2015 8:13 PM To: Lang Hames; Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] MCJit interface question Hey Joseph, What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but

This patch includes one small change: the Processors::get_load_average() method is now const since it does not change the object's state.