search for: jitlink

...xitOnErr(J->lookup("main")); typedef int (*MainFnPtr)(int, char *[]); auto Result = orc::runAsMain( jitTargetAddressToFunction<MainFnPtr>(MainSym.getAddress()), Args, StringRef("lli")); The Xcode halts the execution when an assertion is triggered in llvm::jitlink::Symbol::constructNamedDef (the full call stack is below). The line that triggers the assertion is this: assert(Offset < Base.getSize() && "Symbol offset is outside block"); because both Offset and Base.getSize() evaluate to 0). The data referred to by the Base block...

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: 4, index: 0* * __compact_unwind: 0x000000000...

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

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 testing. That last one is unusual so I want to expand on it. The llvm-jitlink tool...

...de unblocked another prototype I've been working on: an OrcRPC based TargetProcessControl implementation. I've added that to the "orcv1-removal-with-remote-tpc" branch at https://github.com/lhames/llvm-project. The easiest way to start playing with this feature is via the new llvm-jitlink options: -oop-executor, and -oop-executor-connect. The -oop-executor option will fork and exec the llvm-jitlink-executor program and connect to it via open file descriptors (similar to how lli-child-target works). The -oop-executor-connect option will connect to a listening llvm-jitlink-executor pr...

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

...ffort is now focused on ORCv2. If you are an ORCv1 client, now's the time to switch over. If you need help please ask on the llvm-dev mailing lists (make sure you CC me) or #llvm on discord. There are also some tips available in https://llvm.org/docs/ORCv2.html . (2) LLVM has a new JIT linker, JITLink, which is intended as an eventual replacement for RuntimeDyld. The new design supports linker plugins (allowing operation on the low-level bits generated by the JIT linker) and native code models (RuntimeDyld required a custom code model on some platforms). Currently JITLink only supports Darwin x8...

...e registered with the Objective-C runtime). While this system is still very new, it is far enough along that the lli command line tool, when run with the -jit-mode=orc-lazy option, can now execute simple IR compiled from simple Objective C and Swift programs on Darwin. Also of interest this week: JITLink has a new "GOT and Stub bypass" optimization for x86-64. When linking position independent code, JITLink must conservatively build global offset table entries and stubs to access/call external symbols that may be out of range of the JIT'd code. With this new optimization, these indire...

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

...03 . I don't have time to implement it just yet, but I would be very happy to provide support and review patches if anyone else wants to give it a shot. What's the capability level of ORCv2 on RuntimeDyld compared to ORCv1? > Are there features supported in v1 that are only available on JITLink > supported platforms? At a high level, ORCv2's design allows for basically the same features as ORCv1, plus concurrent compilation. There are still a number of APIs that haven't been hooked up or implemented though. Most prominently: Event listeners and removable code. If you're u...

...ot > 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 community are working on an ELF/x86-64 implementation of JITLink at the moment -- Once we have that you should get small code model support and better error handling. -- Lang. On Fri, Oct 2, 2020 at 4:03 AM Geoff Levner <glevner at gmail.com> wrote: > StaticLibraryDefinitionGenerator works as promised on ELF archives! > > I have only encountere...

...er. If you've been wanting to move to ORC but held up by lack of debugger / profiler registration, chime in on the review -- I'd appreciate feedback and help with testing. I will also post a bug tomorrow for investigating similar (or hopefully better) debugger registration functionality for JITLink. The other news is that Swift's immediate mode has moved from MCJIT to LLJIT. The first patch for this was posted on GitHub a few weeks back, but blocked while I tracked down some failures in Swift script test cases on Linux. Those failures have now been fixed and Swift's immediate mode m...

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

...ks like we'll have an opportunity to set up impromptu meet-ups too (see https://www.youtube.com/watch?v=Qpbefagv6Ts) so if you want to do a deeper dive on a topic area we can set one or more of those up -- just let me know in this thread. Topics so far: A very brief status update on OrcV2 and JITLink. Future / Potential use-cases for the JIT. -- LLDB, the Swift interpreter, REPLs. Compile time improvements -- Experimenting with / performance-testing custom JIT pipelines (any volunteers?) -- Compile-time improvements for the existing pipeline. This is probably a broad community project,...

...bd41aad154bd7e67313fcb36c401a0c65d55652>. You may just be able to mark your externs as __dllimport for this to work. I don't recall whether __dllimport works for data symbols too, but I suspect so -- I think it's basically an explicit GOT entry. If anyone is ever interested in writing a JITLink COFF implementation I will be happy to help out or review patches -- I'd love to get better COFF support in tree. -- Lang. On Fri, Aug 21, 2020 at 2:09 PM Stefan Gränitz <stefan.graenitz at gmail.com<mailto:stefan.graenitz at gmail.com>> wrote: Hi Björn I made a workaround for...

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

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

...his 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 identify who is interested in working on this. My pitch: We should solve this by investing in JITLink and implementing profiling (and debugger support) via ObjectLinkingLayer::Plugins. Maybe a brief overview of / discussion on how these work would be useful? -- Lang. On Fri, Sep 25, 2020 at 7:19 PM Andres Freund <andres at anarazel.de> wrote: > Hi, > > On 2020-09-25 19:05:42 -070...

...will be (re)committed along with some example code as soon as I work out the kinks in the object buffer ownership -- Hopefully Monday or Tuesday this week. LLJIT now enables exception handling for MachO by default (7266a8bfeb8). RuntimeDyldCOFF will now build stubs for dllimports (337e131ca7de). JITLink now correctly scopes MachO linker-private symbols (b64afadf306, 9c9eb60b4b), and reads the 'weak' flag from the correct nlist field (c700e0317c2). Stackmaps and DWARF can now be used in the same file without triggering an assertion (3f981cdde90f). -- Lang. -------------- next part -------...

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]