similar to: ORC JIT Weekly #3 -- No JIT updates this week.

Hi All, This was a quiet week -- the only significant ORC change was to the new TargetProcessControl API [1], which acquired the ability to load libraries and search for symbols in the target process in [2]. A new TargetProcessControl based definition generator is included to take advantage of this, and the LLJITWithTargetProcessControl example has been updated to include it. Regards, Lang. [1]

Hi All, I'm back again after a couple of weeks hiatus, and I have some good news for anyone interested in cross-process JITing with OrcV2: The remote TargetProcessControl and Orc library breakup patch has landed in 1d0676b54c4 [1]. Thanks very much to Dave Blaikie and Stefan Graenitz for all their feedback on the review! As described in my last email, this commit breaks the OrcJIT library

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

Hi All, There was no update last week -- I'm still trying to get back into a regular schedule. Open-source changes since the last update were: (1) Some bug fixes for JITLink MachO / arm64 support (PAGE21/PAGEOFF12 now handle addends correctly). (2) llvm-jitlink now supports loading archives as well as relocatable objects. (3) llvm-jitlink now supports basic object-file level mocking and

Hi Björn I made a workaround for this specific issue a long time ago for the Projucer C++ JIT Engine. It basically forwards the call to another stub that provides enough space to encode a full 64-bit address. The patch is based on LLVM 3.9, so I guess it won't work out-of-the-box on a recent release, but it may give you enough hints to figure it out on your own:

Hey Lang and Stefan, Using dllimport on my “planschiValue” actually worked! But I have no idea why, because the relocation is still a REL32 if I use dumpbin… So how is it possible for that to work? However… when I load an COFF object file, am I able to change the relocations to dllimport somehow? I honestly can’t imagine how this would work since the machine code is probably already adjusted to

Hey Lang, That is really cool :D Is the creation of that table a Windows thingy or is this the way the LLVM handles it? Also… since it is COFF related – the never ending story of “finding my global constructors” first of all: Yes! I tried using the “initialize” function of LLVMJIT – however this only worked when I was loading a Module. When I added the object file (from the same source) the

Hi Stefan Thank you! In case, you missed in llvm-dev listing: you can find the proposal here : link. <https://docs.google.com/document/d/1202EcXlWMQ8yxu5qD0b5fE0a_kihlcaPNpZo_Jk0YeQ/edit?usp=sharing> Thanks for working on summarising the Bugzilla tickets to track the recent changes in ORC this is really helpful. On Sat, 18 May 2019 at 21:33, Stefan Gränitz <stefan.graenitz at

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 everyone A previous thread about OrcJIT brought up bug reports on Bugzilla. A quick search gives 20+ results: https://bugs.llvm.org/buglist.cgi?component=OrcJIT&list_id=162232&query_format=advanced&resolution=--- While some of them are obviously outdated (addModuleSet API cleanup [1]), others may actually be relevant again (Small code model? [2]). If you reported one of them,

"git remote get-url" is apparently fairly new, the old version is "git config remote.origin.url". Might be worth using that for compatibility. On Mon, Jul 29, 2019, 5:11 PM Stefan Gränitz <stefan.graenitz at gmail.com> wrote: > Hey Cam, it works for me on TOT (89fb9e8ce15). > > What does the failed command return for you? It should be: > > > git

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:

Hi Igor, not sure if that will work, but have you tried lli -jit-kind=orc-lazy ? The default is still MCJIT: https://github.com/llvm/llvm-project/blob/master/llvm/tools/lli/lli.cpp#L88 On 13/01/2020 19:07, David Blaikie via llvm-dev wrote: > (+Lang for JIT/interpreter questions) > > On Sun, Jan 5, 2020 at 5:00 PM Igor Gomon via llvm-dev > <llvm-dev at lists.llvm.org

Hey LLVM-Mailing-List and Lang, I'm still learning how to use the ORC JIT but I finally reached the point to JIT and execute some code. For this purpose I created a test file (TestModule.cpp) and compiled it with Clang, generating two different files, one in the LLVM IR format and one in the Microsoft COFF format. The JIT resolves all undefined references, including "extern int

Hi all, I am following the LLVM JIT tutorial API based on: https://llvm.org/docs/tutorial/BuildingAJIT1.html I have 2 independent questions: 1. The tutorial mentions that "*will defer compilation of the module until any of its definitions is looked up*". Does that mean to force eager compilation, i have to keep track of all functions added to the Module and do a lookup? I want the

Hi Stefan, I just tried the -jit-kind=orc-lazy with lli executable and it solves the problem on Ubuntu 18.04 (still does not work on Windows 10). But this solution is good enough for me now. Thanks again for your help! -- Best Regards, Igor ________________________________ From: Igor Gomon <giv_ua at hotmail.com> Sent: Tuesday, January 14, 2020 7:38 PM To: Stefan Gränitz

Hi Dibyendu > On Windows 10 64-bit, with > dynamic linking - I found one unexpected behaviour - the findSymbol() > is unable to locate the JIT compiled function in the module if search > for "exported" only is true ... even though the function is defined as > having ExternalLinkage. I have to test on Linux / Mac OSX to see if > the behaviour is different there.

No issues pushing commits here, (despite it being my first commit via git!). On Thu, 13 Jun 2019 at 15:11, Stefan Gränitz <stefan.graenitz at gmail.com> wrote: > It looks like the lab.llvm.org build bot status page has been down for a > while. > > Yes, same here. Additionally, having trouble pushing commits to the > monorepo: > > $ git llvm push -n > Pushing 1

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

Hi all In case anyone has a remote to the (unofficial) https://github.com/llvm-mirror, please note that all the repos are at least 8 days behind. There's no warning about it. The page still says it's "Updated every five minutes". Best Stefan -- https://flowcrypt.com/pub/stefan.graenitz at gmail.com