similar to: dynamic namespacing of JIT modules?

Hi Geoff, We use LLJIT. Do addObjectFile() and StaticLibraryDefinitionGenerator work > for ELF objects? They do. :) I've not tested StaticLibraryDefinitionGenerator extensively on Linux. but we have a regression test checking basic usage. If you run into any trouble at all please file a bug and assign it to me. -- Lang. On Mon, Sep 28, 2020 at 2:05 PM Geoff Levner <glevner at

Hi Geoff, Importing symbols into the JIT from an object file or static library...? Sure! Are you interested in doing this with the C API, LLJIT, or raw OrcV2 components? The high-level answer here (which we can dig into further in the BoF) is: For object files: - For raw OrcV2 components you'll want to create an RTDyldObjectLinkingLayer or ObjectLinkingLayer and use the 'add'

Greetings, LLVM wizards. I am using clang to compile a C++ module, and an ExecutionEngine (MCJIT) to execute a function it defines. That works (or pretends to). However, if I call the module's constructors first: exec_engine->runStaticConstructorsDestructors(false); exec_engine->runFunctionAsMain(function, argvec, NULL); execution still works, but my program crashes when it exits, in

On Alex's advice I am switching from MCJIT to the Orc API to compile and execute functions. Starting from the new clang-interpreter example in the source code (top of the tree!), I am able to execute my functions all right... as long as there are no constructors and destructors to call. My question: is there a simple way, with the Orc API, to run a module's constructors and destructors? I

When OrcMCJITReplacement is given a new module, it asks for the module's constructors, gives them names like $static_ctor.0, $static_ctor.1, etc., and saves the mangled names in a map. Later, to execute them, it uses runViaLayer(), which looks for those symbol names in the given JIT layer. Could one not simply execute the constructors straight away, rather than naming them and looking them up

Hi All, I've listed the current topics of interest below, along with some notes on each. We only have 30 minutes so we'll barely scratch the surface of these during the BoF itself. My main aims are for you to meet each other, identify potential areas of collaboration, identify things that I can do to unblock you, and get the ball rolling on some conversations that we can continue on the

Many thanks for the sample code, Alex. In the end I did it the same way OrcMCJITReplacement does it. Constructors and destructors are called and, thanks to LocalCXXRuntimeOverrides, the program does not crash on exit! But it does seem like there should be a simpler way; the learning curve is steep... Geoff On Thu, 21 Jun 2018 at 12:28, Alex Denisov <1101.debian at gmail.com> wrote: >

Hi Geoff, hi Alex If you implement the GDB JIT Interface in your Orc JIT, this is in general possible (at least from the JIT's point of view) with both debuggers, GDB and LLDB. Please have a look at the example here: https://github.com/weliveindetail/JitFromScratch/tree/jit-debug/gdb-interface You will probably need to adjust the code depending on the LLVM version you are using. As described

Hi Andres, A topic that I'd find interesting is what it'd take to make it easier to > use profile guided optimization in the context of JIT. A few years back > I crudely hacked this together, but it was fairly ugly. It'd be nice to > make that easier. Possibly too complicated for that type of session? We couldn't go into detail, but we could kick off a discussion and

Hi, On 2018-07-19 14:57:42 +0200, Frank Tetzel via llvm-dev wrote: > > Have you seen https://reviews.llvm.org/D44892? we are using it in > > Julia to use perf on jitted code. > > No, I did not see this patch before. Thanks a lot for the pointer. > > It seems to be doing exactly what I want. Let's see if I get it working. FWIW, I just merged this. Did you have any

Greetings, LLVM wizards. I was just wondering if any progress has been made on this issue in the last few months (using gdb to debug a module compiled by Orc). I had to move to the Orc API in order to be able to call modules' constructors and destructors as needed, but I would quite like to be able to debug and profile the resulting code as well... Thanks, Geoff -------------- next part

No, the problem is that Finalized is true. It is set to true at the start of the finalize() method. That's why I added a test causing that line to be executed if the symbol's address is zero... On Tue, 17 Sep 2019, 00:05 Lang Hames, <lhames at gmail.com> wrote: > Hi Geoff, > > Oof. I don't know what this is yet, but I bet it's going to be awful. > Quick apology

I have found the cause of our problems with implicit template instantiation, and it looks to me like a bug in Orc JIT in LLVM 8. (Perhaps Lang could confirm?) We use createLegacyLookupResolver() to create our symbol resolver, passing it a lookup function. Amongst other things, our function calls LegacyRTDyldObjectLinkingLayer::findSymbol() to look up symbols in the JIT. When a module is

You can add symbols from Archieve via StaticLibrarySearchGenerator. But it is added recently though On Tue, 27 Aug 2019 at 21:02, Praveen Velliengiri < praveenvelliengiri at gmail.com> wrote: > Hi Geoff, > I tried it, but I can't able to reproduce it. > > Test Program: > #include <fstream> > int main() > { > std::ifstream stream1, stream2; >

On Tue, Aug 27, 2019 at 4:56 PM Praveen Velliengiri <praveenvelliengiri at gmail.com> wrote: > > HI > Did you run the static constructor and destructor? How did you make your process symbols visible to ORC jit? Yes. It's the constructor that generates the undefined symbol error. We use DynamicLibrary::LoadLibraryPermanently(nullptr) to add process symbols. > Could you

Well, I agree the front end must be responsible for (not) instantiating the function templates. However the problem shows up only when JIT compiling, for some reason, and only with LLVM 8. Is there perhaps something else that needs to be done before resolving symbols, in addition to running constructors, to ensure that instantiated function templates are taken into account? Or perhaps there is

Hi All, The general initializer support patch has landed (see 85fb997659b plus follow up fixes). Some quick background: Until now ORC, like MCJIT, has handled static initializer discovery by searching for llvm.global_ctors and llvm.global_dtors arrays in the IR added to the JIT. This approach suffers from several drawbacks: 1) It provides no built-in support for other program representations:

Greetings, LLVM wizards. We are using Clang and Orc JIT (v1) to compile and execute C++ code on the fly. If a C++ module calls functions from external libraries, we add them via DynamicLibrary::LoadLibraryPermanently(). The problem we have run into recently is when a module calls a function from the STL -- in particular this swap() function for input streams: #include <fstream>

Hi Andres, Ok -- I've added some API for this in 438db0719681: You can get the string pool from the execution session with LLVMOrcExecutionSessionGetSymbolStringPool, then clear that with LLVMOrcSymbolStringPoolClearDeadEntries. -- Lang. On Thu, Oct 1, 2020 at 5:34 PM Lang Hames <lhames at gmail.com> wrote: > Hi Andres, > > Oooh. I think I see. For various reasons the symbol

On 05/05/18 17:58, Andres Freund wrote: > You're building LLVM with assertions enabled > (-DLLVM_ENABLE_ASSERTIONS=ON). > Some of those are fairly expensive... > Is there another way to get LLVM to check the correctness of my IR without the assertions? That's what I'm assuming I need the flag for (it's been a long time since I experimented with it) If there is no way