similar to: Linking existing functions from JITed code

Hi Andy, I haven't tested this on Linux, but on MacOS the RuntimeDyldMemorManager::getSymbolAddressInProcess method should find symbol addresses in the host program, including symbols from static archives linked into the program. However, one gotcha is that the symbol has to be reachable from main, otherwise the linker may strip it from the final executable. Do you have a test-case that I

Hi Andy, I think that makes sense. I'm currently rewriting the core Kaleidoscope tutorials - I'll look at adding support for this. - Lang. On Fri, Aug 14, 2015 at 7:38 AM, Andy Somogyi <andy.somogyi at gmail.com> wrote: > After some fiddling with it, it does in fact look like it works as you > describe Lang. > > The trick was you had to call > >

Lang, I added the add/get global mapping to my kaleidoscope JIT, but I think perhaps these would make more sense if they were added to the object linking layer as they would be generally usable there. On Aug 19, 2015, at 11:19 PM, Andy Somogyi wrote: > Hey Lang, > > I've added this to my Kaleidoscope JIT, and it seems to work just fine, basically I copied the global mapping

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

Thanks so much! This seems to do the trick. I would have spun my wheels for a long time before discovering all of this, wow. Do I even want to know what additional chickens need to be sacrificed to get this to work on Windows? -- lg > On May 18, 2016, at 1:52 PM, Lang Hames <lhames at gmail.com> wrote: > > Hi Larry, > > You're basically there, but you're hitting

Hi Larry, Thanks so much! This seems to do the trick. I would have spun my wheels for > a long time before discovering all of this, wow. No worries. :) I'll try to keep this in mind and make sure I address it in future Kaleidoscope tutorial chapters - these issues tripped me up the first time I encountered them too. Do I even want to know what additional chickens need to be sacrificed

>> llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr) This is one is a bit tricky and hard to find. I spent quiet some time digging into MC and ORC JIT execution engines trying to find what makes them work. The problem is that this trick (LoadLibraryPermanently) happens inside of EngineBuilder, despite that the functionality belongs to a JIT engine itself, not to the builder. I

Tried that, still didn't work. Then I tried making a direct API call, GetProcAddress(GetModuleHandle(0),"foo") And this works if and only if __declspec(dllexport) is supplied. So it looks like we were both right. On Sat, Apr 2, 2016 at 9:29 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Have you tried to add dllexport? > > On Sat, Apr 2, 2016 at 4:23 PM

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:

Hi, I'm currently working my way through the tutorial with LLVM 3.9.1 on Windows (finished chapter 4) and stumbled over a few things which could be improved: - "LLVMContext" does not exist as a variable -> "TheContext" - Chapter 3: 5 times - Chapter 4: 1 time - Chapter 5: 4 times - Chapter 6: 2 times - Chapter 7: 2 times 3.4. Function Code

We use an explicit relocation step to deal with this. We generate code into a temporary memory location, then relocate it into a reserved area of memory which is always within a small relative offset of other interesting code. This allows us to get pc relative calls. Philip On 03/30/2016 05:53 AM, Matt Godbolt wrote: > For what it's worth we did a similar thing, but > overrode

I am upgrading our JIT application to use LLVM 6.0.0, and with this transition I am making the move to use the new MCJIT facility. A problem I am encountering is that the math functions from libm are not resolved/found. I am using the lambda resolver from the KaleidoscopeJIT class which first searches the present modules and, if that is unsuccessful, continues the search in the whole process

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'm attempting to port some code which uses the GlobalMappingLayer in the Orc JIT. This code worked fine in LLVM 4, but I'm getting a compile error with LLVM 5. I think the problem is that this layer hasn't been modified to account for some of the changes made in LLVM 5, but I wanted to make sure that I wasn't missing something. I have code which looks like this:

I've finally managed to extract from Kaleidoscope one particular thing that it seems to me should be working and isn't. Given the global declaration extern "C" void foo() {} within the same program I have RTDyldMemoryManager::getSymbolAddressInProcess("foo") And it's returning null. (LLVM 3.8, Windows 7 x64.) What am I missing? -------------- next part

Hi, Not sure whether this matches your use case, but the Orc-based JIT used in LLI appears to be using `llvm::orc::LocalCXXRuntimeOverrides` (http://llvm.org/doxygen/classllvm_1_1orc_1_1LocalCXXRuntimeOverrides.html) to override `__cxa_atexit`: https://github.com/llvm-mirror/llvm/blob/release_50/tools/lli/OrcLazyJIT.h#L74

Hi Alex, loading the symbols explicitly helped. With this the build process doesn't need any additional linker flags. Very nice. Thanks, Frank On 06/28/2018 04:38 PM, Alex Denisov wrote: > Hi Frank, > > If I am not mistaken it doesn't look in the whole process space by default. > Please, try loading all the symbols explicitly: > >

Hi Brian, Yes - I believe you're correct. I'm working on a fix and extra test coverage now. In the meantime, I believe you should be able to fix the signatures in your copy and everything should "just work". Cheers, Lang. On Fri, Sep 22, 2017 at 2:04 PM, Brian Kahne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > > > I’m attempting to port

Hi all, I'm trying to add pre-compiled object cache to my run-time. I've implemented the object cache as follow: class EngineObjectCache : public llvm::ObjectCache { private: std::unordered_map<std::string, std::unique_ptr<llvm::MemoryBuffer>> CachedObjs; public: virtual void notifyObjectCompiled(const llvm::Module *M, llvm::MemoryBufferRef Obj) { auto id =

Hi All. I have an issue when a MCJIT ExecutionEngine is created then deleted, any C++ exception thrown after the MCJIT dtor is called will result in a seg fault. This does not occur with the regular JIT engine, and only occurs on Linux, works fine on OSX. basically its like this: ExecutionEngine *e = engineBuilder.create(); // this is fine try { throw exception()} catch(exception&) {}