search for: loadedobjectinfo

...;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::JITEvaluatedSymbol,std::less<llvm::StringRef>,std::allocator<std::pair<llvm::StringRef const ,llvm::JITEvaluatedSymbol>>> Resolved, std::set<llvm::StringRef,st...

...LinkingLayer::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 LoadedObjectInfo &)>;                                                     ^^^^^^^^^^^^^^^^ It refers to llvm::LoadedObjectInfo base class in llvm/DebugInfo/DIContext.h instead of   llvm::RuntimeDyld::LoadedObjectInfo in llvm/ExecutionEngine/RuntimeDyld.h I think it should actually use the derived RuntimeDyl...

Hi Lang, LoadedObjectInfo::getSectionLoadAddress takes StringRef as an arg. That breaks if the object file has multiple sections with the same name. I made a change to add an overload that takes a SectionRef&. Can you please take a look? https://github.com/erozenfeld/llvm/commit/65f635e426bdc8e80a29ed370a78f0c0a282f265...

On Wed, Jul 22, 2015 at 9:41 PM, Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com> wrote: > Hi Lang, > > > > LoadedObjectInfo::getSectionLoadAddress takes StringRef as an arg. That > breaks if the object file has multiple sections with the same name. I made a > change to add an overload that takes a SectionRef&. Can you please take a > look? > > > > https://github.com/erozenfeld/llvm/commit/65f635...

...eviews.llvm.org/D11474 Eugene -----Original Message----- From: Meador Inge [mailto:meadori at gmail.com] Sent: Thursday, July 23, 2015 8:45 AM To: Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com> Cc: Lang Hames <lhames at gmail.com>; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] LoadedObjectInfo::getSectionLoadAddress On Wed, Jul 22, 2015 at 9:41 PM, Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com> wrote: > Hi Lang, > > > > LoadedObjectInfo::getSectionLoadAddress takes StringRef as an arg. > That breaks if the object file has multiple sections with the same...

...lir_project/llvm-project/llvm/lib/ExecutionEngine/GDBRegistrationListener.cpp", line=line at entry=164, function=function at entry=0x7ffff1d15520 <(anonymous namespace)::GDBJITRegistrationListener::notifyObjectLoaded(unsigned long, llvm::object::ObjectFile const&, llvm::RuntimeDyld::LoadedObjectInfo const&)::__PRETTY_FUNCTION__> "virtual void {anonymous}::GDBJITRegistrationListener::notifyObjectLoaded(llvm::JITEventListener::ObjectKey, const llvm::object::ObjectFile&, const llvm::RuntimeDyld::LoadedObjectInfo&)") at assert.c:101 #4 0x00007ffff01ed4d3 in (anonymous...

...gine/GDBRegistrationListener.cpp", >> line=line at entry=164, >> >> function=function at entry=0x7ffff1d15520 <(anonymous >> namespace)::GDBJITRegistrationListener::notifyObjectLoaded(unsigned long, >> llvm::object::ObjectFile const&, llvm::RuntimeDyld::LoadedObjectInfo >> const&)::__PRETTY_FUNCTION__> "virtual void >> {anonymous}::GDBJITRegistrationListener::notifyObjectLoaded(llvm::JITEventListener::ObjectKey, >> const llvm::object::ObjectFile&, const >> llvm::RuntimeDyld::LoadedObjectInfo&)") >> >>...

...lir/lib/ExecutionEngine/ExecutionEngine.cpp has the following code with highlighted debug statement added by me: objectLayer->setNotifyLoaded( [engine = engine.get()]( llvm::orc::VModuleKey, const llvm::object::ObjectFile &object, const llvm::RuntimeDyld::LoadedObjectInfo &objectInfo) { if (engine->gdbListener) { uint64_t key = static_cast<uint64_t>( reinterpret_cast<uintptr_t>(object.getData().data())); dbgs() << "ExecutionEngine key = " << key << "\n";...

...oad the object into the dynamic linker. // MCJIT now owns the ObjectImage pointer (via its LoadedObjects list). ErrorOr<std::unique_ptr<object::ObjectFile>> LoadedObject = object::ObjectFile::createObjectFile(ObjectToLoad->getMemBufferRef()); std::unique_ptr<RuntimeDyld::LoadedObjectInfo> L = Dyld.loadObject(*LoadedObject.get()); if (Dyld.hasError()) report_fatal_error(Dyld.getErrorString()); after the generateCodeForModule call, the findExistingSymbol is invoked. For some reason it cannot find my symbol. My symbol exists in the Module that was used as input for gen...

...bject is loaded and when it is finalized. So I'd expect e.g. if you're listening to the loading event then you could create a functor class (with signature similar to DoNothingOnNotifyLoaded), put your logic in its operator() (changing to allow that you'll now be passed sets of Objects/LoadedObjectInfos), then change LLILCJit's LoaderT typedef to supply your functor type as the template argument and change the Loader constructor to supply an instance of the functor. From: Michelle McDaniel Sent: Thursday, June 4, 2015 1:27 PM To: Lang Hames; Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu<mai...

...rString()); > > - NotifyObjectEmitted(*LoadedObject.get(), *L); > - > + // Can't call notifiers yet as relocations have not yet been performed, and > + // memory hasn't been marked executable. > + PendingLoadedObjects.push_back(LoadedObject->get()); > + PendingLoadedObjectInfos.push_back(std::move(L)); > Buffers.push_back(std::move(ObjectToLoad)); > LoadedObjects.push_back(std::move(*LoadedObject)); > > @@ -243,6 +245,16 @@ void MCJIT::finalizeLoadedModules() { > > // Set page permissions. > MemMgr->finalizeMemory(); > + > +...

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed

Hi, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that

Hi all, So I’m also working on LLILC. Specifically, I have been working on a JITEventListener to pass debug line info to the CoreCLR EE. With Joe’s change, I’ve lost the ability (or as far as I can tell) to attach an event listener. Is there a way within Orc to do the sorts of things that the JITEventListeners do in MCJIT? How would I go about adding a layer to add debugging support? Thanks,

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