search for: rtdyldobjectlinkinglay

Hi all, hi Lang It's a little late to report issues for release_50, but I just found that thing while porting my JitFromScratch examples to 5.0. This is a really nifty detail, but (if I'm not mistaken) the function signature of RTDyldObjectLinkingLayer::NotifyLoadedFtor is incorrect: $ grep -h -r -A 1 "using NotifyLoadedFtor" ./include/llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h   using NotifyLoadedFtor = std::function<void(ObjHandleT, const ObjectPtr &Obj,                                               const LoadedObje...

In certain circumstances, RTDyldObjectLinkingLayer dereferences a null pointer. Specifically, that happens if you add a linking object which, for some reason, is never finalized, and you specify a function to be called when objects are freed. Admittedly, that must not happen very often, but it can happen in our application, causing it to crash....

...tually use a JIT successfully? It'd not be too bad if I had to use a small bit of, optional, code to register a JIT event listener, but otherwise use the C API (that's what I currently do for perf support in MCJIT), but it doesn't look like that's an option with the ORC C bindings (RTDyldObjectLinkingLayer's integration is a class template parameter defaulting to DoNothingOnNotifyLoaded), and it's not used by OrcCBindingsStack. In addition, it doesn't currently look there's C API to force the mcjit replacement being used? Is there interest in addressing these issues, or is the pos...

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 / profiler registration, chime in on the review -- I'd appreciate feedbac...

...sure where exactly they're coming from. Possible that I'm just missing a > > step somewhere. Or something around the removable code support doesn't > > yet fully work. > > I just checked and I've migrated ObjectLinkingLayer to support > ResourceTracker, but not RTDyldObjectLinkingLayer yet. If you're testing on > Linux there's a good chance that's the source of your leak. I'll get that > updated tonight. I indeed am testing on linux... Thanks. Regards, Andres

...Dyld::LoadedObjectInfo const&)>::operator()(unsigned long, llvm::object::ObjectFile const&, llvm::RuntimeDyld::LoadedObjectInfo const&) const (__args#2=..., __args#1=..., __args#0=<optimized out>, this=0x5555594e09b8) at /usr/include/c++/7/bits/std_function.h:706 #6 llvm::orc::RTDyldObjectLinkingLayer::onObjLoad (this=<optimized out>, K=3, R=..., Obj=..., MemMgr=0x5555591c4160, LoadedObjInfo=std::unique_ptr<llvm::RuntimeDyld::LoadedObjectInfo> = {...}, Resolved=std::map with 8 elements = {...}, InternalSymbols=std::set with 0 elements) at /localdisk/adstraw/ngraph/build/mli...

.../../include/x86_64-linux-gnu/c++/6.3.0/usr/lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/backward /usr/local/include /usr/local/bin/../lib/clang/4.0.1/include /usr/include/x86_64-linux-gnu /usr/include Endof search list.| The error I get is this: error: unknown type name 'RTDyldObjectLinkingLayer'; did you mean 'RTDyldObjectLinkingLayerBase'? Moreover, I get more errors. This tells me something is wrong with the templating. error: too many template arguments for class template 'IRCompileLayer' IRCompileLayer CompileLayer; Another error with regards to R...

...ility::notifyResolved(const llvm::DenseMap<llvm::orc::SymbolStringPtr,llvm::JITEvaluatedSymbol,llvm::DenseMapInfo<llvm::orc::SymbolStringPtr>,llvm::detail::DenseMapPair<llvm::orc::SymbolStringPtr,llvm::JITEvaluatedSymbol>> & Symbols) Line 449 C++ libravi.dll!llvm::orc::RTDyldObjectLinkingLayer::onObjLoad(unsigned __int64 K, llvm::orc::MaterializationResponsibility & R, llvm::object::ObjectFile & Obj, std::unique_ptr<llvm::RuntimeDyld::LoadedObjectInfo,std::default_delete<llvm::RuntimeDyld::LoadedObjectInfo>> LoadedObjInfo, std::map<llvm::StringRef,llvm::JITEvalua...

...tor()(unsigned long, llvm::object::ObjectFile const&, >> llvm::RuntimeDyld::LoadedObjectInfo const&) const (__args#2=..., >> __args#1=..., __args#0=<optimized out>, this=0x5555594e09b8) at >> /usr/include/c++/7/bits/std_function.h:706 >> >> #6 llvm::orc::RTDyldObjectLinkingLayer::onObjLoad (this=<optimized out>, >> K=3, R=..., Obj=..., MemMgr=0x5555591c4160, >> LoadedObjInfo=std::unique_ptr<llvm::RuntimeDyld::LoadedObjectInfo> = {...}, >> >> Resolved=std::map with 8 elements = {...}, InternalSymbols=std::set >> with 0 element...

...ith the ResponsibiltySet. When it is created it tries to to find symbols for all the names it knows about. Eventually the look up request ends up in my application where I use a LegacyIRCompileLayer to search for the symbol in the jitted module. That function call eventually ends up in getSymbol in RTDyldObjectLinkingLayer.h where the symbol is found but it does not have and address (Address is zero and Flags is 50). So an instance of JITSymbol is returned to the LegacyRTDyldObjectLinkingLayer and the findSymbol function which checks if an valid symbol was found (on line 406 in RTDyldObjectLinkingLayer.h). Since th...

Trying to put together a simple test JIT compiler, using ORC which as I understand it will be the supported API going forward, I noticed that in the first chapter of the updated Kaleidoscope tutorial, there is sample code that starts like this: ExecutionSession ES; RTDyldObjectLinkingLayer ObjectLayer; IRCompileLayer CompileLayer; DataLayout DL; MangleAndInterner Mangle; ThreadSafeContext Ctx; But in https://llvm.org/devmtg/2016-11/Slides/Hames-ORC.pdf there is sample code that looks like this: ObjectLinkingLayer LinkLayer; SimpleCompiler Compiler(TargetMachine()); IRCompileLaye...

...the “Adding MemMgr 0x55555959f440“ message as “Registering MemMgr 0x55555959f440”. Thus the address mismatch made no sense. How could we be registering a `MemMgr` address/key that does not match once we arrive in `notifyObjectLoaded` method? Answer: Because the registrations is NOT coming from RTDyldObjectLinkingLayer.cpp. I found this first by adding an additional debug statement (highlighted) thinking the `reinterpret_cast` may be at fault for the key mismatch. I never saw this print and I then realized my “Adding” vs. “Registering” mistake. // Run EventListener notifyLoaded callbacks. { std::lock...

...size vs. prev_size" depends on the IR code generated from the source code. Here's how I created the JIT: llvm::InitializeNativeTarget(); llvm::InitializeNativeTargetAsmPrinter(); llvm::InitializeNativeTargetAsmParser(); // create jit llvm::orc::ExecutionSession ES; llvm::orc::RTDyldObjectLinkingLayer ObjectLayer(ES, []() { return std::make_unique<llvm::SectionMemoryManager>(); }); auto JTMB = llvm::orc::JITTargetMachineBuilder::detectHost(); auto DL = JTMB->getDefaultDataLayoutForTarget(); llvm::orc::IRCompileLayer CompileLayer(...

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 Yichao, RTDyldObjectLinkingLayer has a NotifyObjectLoaded hook that you can use to call NotifyObjectEmitted on your GDBRegistrationListener. If code is going to be unloaded we would have to add an extra hook to call NotifyFreeingObject -- that seems totally reasonable to add. -- Lang. On Wed, Oct 11, 2017 at 10:44 AM, Yichao...

...ySet. When it is created > it tries to to find symbols for all the names it knows about. Eventually > the look up request ends up in my application where I use a > LegacyIRCompileLayer to search for the symbol in the jitted module. That > function call eventually ends up in getSymbol in RTDyldObjectLinkingLayer.h > where the symbol is found but it does not have and address (Address is zero > and Flags is 50). So an instance of JITSymbol is returned to the > LegacyRTDyldObjectLinkingLayer and the findSymbol function which checks if > an valid symbol was found (on line 406 in RTDyldObjectLinki...

Hi, On 2020-09-30 17:52:46 -0700, Lang Hames wrote: > I've just realised that we're going to need a change to the definition > generator API in the long term: Right now it is called under the session > lock, but we want to shift to calling it outside the lock and passing a > lookup-continuation. This would allow definition discovery to take an > arbitrarily long time

...is emitted. With the help of Lang I do this now with the lookup function of the Execution Session. Thank you for this! However, my next issue is: How can I find every defined symbol in my object files? Currently I attached a callback function with the "setNotifyLoaded" function of "RTDyldObjectLinkingLayer". Which is really handy, because I can simply iterate over the symbols of the object files. However this only works when I already know what is inside my object files, which kinda kills the purpose. For a workaround I iterate through all the global symbols and functions of the IR module I...

I'm trying to use PerfJITEventListener with llvm::orc::LLJITBuilder: 1. perf record -o /tmp/perf.data -- <my_binary_with_event_listener> 2. perf inject -j -v -i /tmp/perf.data -o /tmp/perf.data.jit *jit marker found: ~.debug/jit/llvm-IR-jit-20200417-3c2242/jit-149849.dump* *injecting: ~/.debug/jit/llvm-IR-jit-20200417-3c2242/jit-149849.dump* *write ELF image

...mbols into the JIT from an object file or static library...? Sure! Are you interested in doing this with the C API, LLJIT, or raw OrcV2 components? The high-level answer here (which we can dig into further in the BoF) is: For object files: - For raw OrcV2 components you'll want to create an RTDyldObjectLinkingLayer or ObjectLinkingLayer and use the 'add' method. - For an LLJIT instance you can just call the 'addObjectFile' method. - For the OrcV2 C API you can call the 'LLVMOrcLLJITAddObjectFile' function. For static libraries: - For raw OrcV2 components or an LLJIT instance you can...