similar to: ORC JIT Weekly #19 -- Relocatable object level mocking with llvm-jitlink.

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

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 All, Everything is landing all at once, just not in the mainline... yet. As discussed in http://lists.llvm.org/pipermail/llvm-dev/2020-September/144885.html: OrcV1 will be removed very soon. I have posted a branch with the removal, "orcv1-removal", in my llvm fork at https://github.com/lhames/llvm-project. In addition to removing OrcV1, the orcv1-removal branch also contains a

Hi Andres, I also want to highlight the necessity of some form of C API, that others > already have. > <snip> > It's fine if the set of "somewhat stable" C APIs doesn't provide all the > possible features, though. Ok. This got me thinking about what a simple LLJIT API should look like. I have posted a sketch of a possible API on http://llvm.org/PR31103 . I

Hi All, In the interests of improving visibility into ORC JIT development I'm going to try writing weekly status updates for the community. I hope they will provide insight into the design and state of development of LLVM's JIT APIs, as well as serving as a convenient space for discussions among LLVM's large and growing community of JIT API users. The length and detail will vary

Hi Geoff, I have only encountered one problem. If a static library has not been > compiled with -fPIC and uses symbols from a shared library, LLJIT does not > complain, but the code may crash without warning when it is executed. Was the static library compiled with large code model too? I think this is probably a RuntimeDyld bug: It's not great at error reporting. A few people in the

Hi All, Just a couple of updates this week: First: there is a preview patch up at https://reviews.llvm.org/D75838 to enable use of JITEventListeners in RTDyldObjectLinkingLayer. I've only done very preliminary testing on it, but was able to debug simple JIT'd programs on Linux using the GDB registration listener. If you've been wanting to move to ORC but held up by lack of debugger /

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

hello folks, I'm working to add runtime updating of code to the OCaml compiler which in its bytecode guise presents no barrier because there is only one linker and it is written in that language and full control is available. With native code on the other hand, there is reliance on the system linker and I got completely lost examining the GNU ld/dl library source code. The prospect of

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 All, I've added a very basic set of C bindings for OrcV2 in 633ea07200e, with an example in llvm/example/OrcV2Examples/BasicOrcV2CBindings. Development of the C APIs is being tracked by http://llvm.org/PR31103 -- if you're interested in C APIs for OrcV2 please get involved. I would especially appreciate feedback and patches from C API users: I don't have a use case for the C APIs

Hi All, The initializer patch review at https://reviews.llvm.org/D74300 has been updated. The new version contains a MachOPlatform implementation that demonstrates how Platforms and ObjectLinkingLayer::Plugins can work together to implement platform specific initialization. In this case, the MachOPlatform installs a plugin that scans objects for __objc_classlist and __objc_selref sections and

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 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 All, This week I've been focused on removing some of the blockers for people transitioning from ORCv1 to ORCv2. Issue #1 (http://llvm.org/PR40074, http://llvm.org/PR44337): When LLVM codegens floating point constants for COFF we produce named constant pool entries of the form __real@<bitval>. These are stored in COFF COMDAT sections [1] which allow duplicate symbol definitions to

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

Hello, Right now I am just using a Generator to look for symbols in my process (which links dynamically against libc / libm). It seems to have no trouble finding every other libc / libm / libc++ / ... symbol so I assumed that it was not necessary to specifically link against libm where these __finite symbols reside: $ nm -D /usr/lib/libm.so.6 | grep finite 0000000000050540 T

Hmm, I'm confused. The DSO is compiled with gcc. Do I need to compile it with clang instead? I don't believe the JITted code uses the thread support library directly, although I suppose it may be hidden with templates and/or inline functions... On Mon, Sep 28, 2020 at 10:43 PM Lang Hames <lhames at gmail.com> wrote: > > Hi Geoff, > > If you want to access the variable