search for: jitdylibs

Hello, I am trying to run this basic C++ hello-world code in my iOS app that has LLVM libraries linked in (the app runs on the actual device - iPad Pro, iOS 13.4.1). #include <iostream> int main (int argh, char *argv[]) { std::cout << "Hello World!" << std::endl; return 0; } So below is the break down of the steps that I do: First I compile this code to an

Hi Lang, Please see below is the trace. -- Thanks, Igor *2020-06-06 12:05:21.016705-0400 CppDevProCompiler[6613:3000073] Running...* *jitLink_MachO: magic = 0xfeedfacf, identifier = "llvm-link.submodule-jitted-objectbuffer"* *jitLink_MachO: cputype = 0x0100000c, cpusubtype = 0x00000000* *Creating normalized sections...* * __text: 0x0000000000000000 -- 0x0000000000000064, align:

Hi On Windows 10 when using a debug build of LLVM 10, I get this assertion failure: Assertion failed: (KV.second.getFlags() & ~WeakFlags) == (I->second & ~WeakFlags) && "Resolving symbol with incorrect flags", file C:\work\github\llvm-10.0.0.src\lib\ExecutionEngine\Orc\Core.cpp, line 450 The same failure occurred in LLVM 9 too: Assertion failed: I->second ==

Hi All, I've updated the orcv1 removal branch ( https://github.com/lhames/llvm-project/tree/orcv1-removal) with an initial patch for removable code. If anyone wants to follow along with the development or share thoughts on the design you're very welcome to. I'll be adding tests and comments this week, but for anyone who wants to take an early look the main elements are defined in

Hi, I'm working on a runtime autotuner that utilizes ORCv2 JIT (I'm closely tracking tip-of-tree), so linking new object files and patching in the new function(s) will happen frequently. One of the concerns my runtime system has is the ability to do one of the following: (1) replacement of the contents of a JITDylib with a new object file [to provide semi-space GC-style reclaiming], (2)

Hi Andres, Cool!I assume this works on "non-native" jitlink platforms as well? Or > just mach? This framework is totally materializer agnostic -- It works for ObjectLinkingLayer (JITLink), RTDyldObjectLinkingLayer (RuntimeDyld), and even materializers that aren't emitted via a linker (e.g. stubs and callbacks). Looks like there's not yet a C API yet - not a problem, just

Hi Dave, Yep. This is JITLink specific, so we could only have observed it on MachO x86-64 or arm64 until recently. It takes a little bit of poking to get IR to produce a zero-lengh section on MachO, but not much. Jared Wyles recently contributed an initial JITLink ELF implementation, so the fix seems timely -- we might have been about to see more of it. -- Lang. On Fri, Jun 19, 2020 at 4:02 PM

Hi All, There was only one interesting ORC-specific commit this week: A new example showing how to initialize and de-initialize JITDylibs has been added in llvm/examples/OrcV2Examples/LLJITWithInitializers. The Extensible RTTI system (https://reviews.llvm.org/D39111) that I posted a while back has landed. While this is not ORC specific, I expect it to be used in upcoming patches to allow ORC clients to check the dynamic type of Mate...

Hi All, A preliminary version of removable code support has been posted for review in https://reviews.llvm.org/D79312. This patch removes all uses of VModuleKeys (except for Legacy layers) and takes a whole-JITDylib-at-a-time approach to removal. Removing whole JITDylibs requires more work from clients (compared to per-module removal): Modules to be removed must be placed into throw-away JITDylibs and re-exports used to make symbol definitions visible at the intended locations. On the other hand restricting removal to whole JITDylibs can help to avoid subtle depend...

Hi All, The Kaleidoscope tutorials have now been updated on the orcv1-removal branch. I will try to summarise the state of the work and provide some examples in the ORC JIT Weekly mailout tomorrow. The short version is that I think this is ready to land on the mainline. If anyone wants to check out the OrcV1 removal branch and provide feedback now is the time. Otherwise I will aim to land the

Hi Andres, Postgres uses removable code support and Orcv1. I does make me quite > worried to see a phase where there'll be no viable way of using both in > llvm. Why isn't the right answer here to at lest develop the > replacement as a set of patches / as a branch that then can be merged as > a whole / shortly after each other, rather than just starting to develop > a

Hey Lang, I would be really happy to only have one LLJIT instance and using multiple JITDylibs. However… it seems like that I don’t know enough to use them. So I wonder… 1. When I add Module A to JITDylib A and Module B to JITDylib B – where will those look for undefined symbols? Will Module A for example: will it only search itself and the MainDylib? Or would it also search in JITDylib...

Nice! Let me try to answer some questions, Before that I have to mention this is ORC version 2 APIs and this is where the project is moving forward. JITDylib is the symbol table, basically for a JIT Symbol it have an associated materializers, (you can think of it like an entity that generate the address for that symbol), Example: compiler are materializers. So to add symbols to your own JIT you

Hi Bjoren, For question 1: As you mentioned, it is used to mangle to the symbol name and interning them, So ORC can find them at runtime in one of the JITDylibs. It would be helpful to know what you tried? (please attach code lines). For question 2: I guess you might be missing to link libraries that your program depend on, you can do that via setting up your dynamiclibrary search generator or getCurrentProcess symbols. Plus, Why do you want to hide them,...

Hello there, I finished Chapter 1 of the Kaleidoscope tutorial for using the Orc JIT API. I played around with some things and ended with some questions. 1. What is the use of "MangleAndInterner"? I read it is used to mangle the name for the lookup search, but I seem to be not able to use it correctly. In my first attempt I used the mangled name of my function

Hello, After commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f we have new warning but only if compiled with GCC: In file included from /path/to/llvm/include/llvm/ExecutionEngine/Orc/ExecutionUtils.h:19:0, from /path/to/llvm/lib/ExecutionEngine/Orc/OrcMCJITReplacement.h:23, from /path/to/llvm/lib/ExecutionEngine/Orc/OrcMCJITReplacement.cpp:9:

Hi Bjoern, CC'ing Lang hames For questions, 1. In short yes, you can replace the memory manager, default one provided is section memory manager. 2. If you mean by " address of already compiled code", yes you can do that. Like this JITDylib.define(absoluteSymbols, ( Your_own_symbol , JITTargetAddress(Address of function))), now ORC can resolve all the references to Your_own_symbol

Hello, I recently hit an issue when JIT'ing my generated IR using llvm::orc::LLJIT. My IR contains the following definition of a global variable: > $_ZZ23TestStaticVarInFunctionbE1x = comdat any > @_ZZ23TestStaticVarInFunctionbE1x = linkonce_odr dso_local global i32 123, > comdat, align 4 > And in my host process, there exists the same symbol. I would expect LLJIT to resolve the

Hello LLVM-Mailing list, in the past I was using the MCJIT (if I understand it correctly) to load IR modules, compile them and execute them. The speciality of this JIT was, that it was writing the compiled code into a shared memory - for a different process to execute them. For that task the JIT used a 'custom' memory manager, memory mapping and also resolved undefined references itself.

I am in the process of porting our ORC code to ORC v2 and LLJIT. Now that I have worked around a problem getting global constructors to be called, everything seems to work unless a module declares a static thread-local variable. In that case I get a "JIT session error" saying that the symbol __ emutls_v.xyz was not found (substitute the mangled variable name for "xyz"). Does