similar to: Static constructors with ORC JIT?

Thank you Alex, I went and implemented a solution along those lines. It works well. It may be worth mentioning static constructors in the Kaleidoscope tutorial. Cheers, Daniele ________________________________________ From: Alex Denisov [1101.debian at gmail.com] Sent: 15 March 2019 08:07 To: Daniele Vettorel Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Static constructors with ORC

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

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

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

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 there, I'm having trouble getting ExecutionEngine->runStaticConstructorsDestructors(module, true) to actually trigger static destructors in my code. The static constructors however do get called. I don't know if this is an LLVM or Clang issue, from looking at the IR (see below) it looks like the destructor is being tied to cxa_atexit, and I wonder if that is not called by

On Fri, Sep 9, 2011 at 1:36 PM, Graham Wakefield <wakefield at mat.ucsb.edu> wrote: > Hi there, > > I'm having trouble getting ExecutionEngine->runStaticConstructorsDestructors(module, true) to actually trigger static destructors in my code. The static constructors however do get called. > > I don't know if this is an LLVM or Clang issue, from looking at the IR (see

Hi, I'm trying to work out the correct way of JITing multiple modules. My original approach was to create a new ExecutionEngine for each Module, however this generates an assert failure. If I create a new ModuleProvider for each new Module and then add this to a single ExecutionEngine then I have a problem with static constructors not being run. With a single module, I can call

Hi Andy, I added the runStaticConstructorsDestructors and FindFunctionNamed functions. This also required making them virtual in EE.h. I'm not sure about FindFunctionNamed: In addition to searching finalized modules, should it search Added and Loaded modules? If it finds a Function in these, should it compile and finalize it before returning the Function* ? I modified the implementation

The short version: When I port our application from LLVM 7 to 8, some JIT-compiled code seems to break the implicit instanciation of C++ templates. That is, when I try to resolve a symbol defined by the code, I get undefined symbols corresponding to methods that are actually function templates. If the code adds explicit template instanciations, the problem goes away. Does anybody have an

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

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

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>

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

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

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

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

When using ORC JIT, I'm having trouble with external function resolution (that is, of a function defined in the app, with C linkage). I add a declaration for the function to my IR, and when I use MCJIT, it finds it and all is well, But when I use ORC JIT (I *think* correctly, at least it closely matches what I see in the tutorial), I get an LLVM error, "Program used external function