search for: runtimedyld

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

...omething has been corrupted. Here is the top of the backtrace from lldb: ---------------------- * thread #1: tid = 0x557509, 0x0000000107e6e066 libLLVM-3.4svn.dylib`llvm::processFDE(unsigned char*, long, long) + 134 at /Users/meister/Development/cando/brcl/externals/src/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldMachO.cpp:35, stop reason = EXC_BAD_ACCESS (code=2, address=0x1102adad1) frame #0: 0x0000000107e6e066 libLLVM-3.4svn.dylib`llvm::processFDE(unsigned char*, long, long) + 134 at /Users/meister/Development/cando/brcl/externals/src/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldMachO.c...

...omething has been corrupted. Here is the top of the backtrace from lldb: ---------------------- * thread #1: tid = 0x557509, 0x0000000107e6e066 libLLVM-3.4svn.dylib`llvm::processFDE(unsigned char*, long, long) + 134 at /Users/meister/Development/cando/brcl/externals/src/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldMachO.cpp:35, stop reason = EXC_BAD_ACCESS (code=2, address=0x1102adad1) frame #0: 0x0000000107e6e066 libLLVM-3.4svn.dylib`llvm::processFDE(unsigned char*, long, long) + 134 at /Users/meister/Development/cando/brcl/externals/src/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldMachO.c...

...;. What I really meant was that this system plays well with lit. Not that your question about using FileCheck would have been any less valid. I did consider using FileCheck for this, but decided it was the wrong approach. The fundamental reason is that there's no demand for textually rendering RuntimeDyld's memory, and developing a textual renderer so that we could output text just to pattern match and re-assemble ints in FileCheck would be a lot of pain for (as far as I can see) no gain. If there's a desire for FileCheck to support expression evaluation we could flesh out this evaluator an...

Hello LLVMDevs, I have written a .cpp file in lib/Target/(some arch)/ and i want to use one of its function in a file in lib/ExecutionEngine/RuntimeDyld/. So is there any specific way to do that. This may be a general question for any one who writes a .cpp file in Target/(any arch)/ and tries to use it somewhere in ExecitionEngine/RuntimeDyld/. Please guide. Thanks, Siddharth -------------- next part -------------- An HTML attachment was scrubbed....

Hi Everyone, For your consideration: A proposal to improve regression test support for RuntimeDyld. Short version: We can make RuntimeDyld far more testable by adding a trivial pointer-expression language that allows us to describe how memory should look post-relocation. Jump down to "The Proposal" for details. Long version: Background: For those unfamiliar with it, RuntimeDyld a c...

...or at intel.com<mailto:andrew.kaylor at intel.com>> wrote: Author: akaylor Date: Mon Aug 19 18:27:43 2013 New Revision: 188726 URL: http://llvm.org/viewvc/llvm-project?rev=188726&view=rev Log: Adding PIC support for ELF on x86_64 platforms Modified: llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.h llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldImpl.h Modified: llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp URL: http://llvm.o...

...) I don't really know the best bikeshed color here. Jim? My lame idea would be: ExecutionEngine -> JIT ExecutionEngine -> JIT/Legacy ExecutionEngine/MCJIT -> JIT/MC ExecutionEngine/OProfileJIT -> JIT/OProfile ExecutionEngine/IntelJITEvenst -> JIT/IntelJITEvents ExecutionEngine/RuntimeDyld -> JIT/RuntimeDyld (maybe RuntimeDyld -> DynamicLoader ? Too direct?) But not sure this is really an accurate model for the logical layering of these libraries?

Hi All, I'm going to be making some API breaking changes to the ORC APIs, and to the RuntimeDyld class (which underlies MCJIT). The changes may affect MCJIT clients but are unlikely to. Where they do the fixes are likely to be trivial. ORC clients will be affected, but the fixes should also be straightforward. I have three upcoming changes in mind: 1) RuntimeDyld (the linker underlying MCJIT...

HI Stefan, CC'ing Reid Kleckner, who might have some insight here, and llvm-dev as this may be of interest to other windows JIT users. I am facing the issue that C++ dynamic_cast doesn't work for types > loaded from object files with RuntimeDyLd. <snip> Do you think it is possible that RuntimeDyLd misses type info data in > the COFF file or doesn't wire it up correctly? > I set ProcessAllSections = true, but I didn't recognize any change. I > found that RuntimeDyLdCOFF does not override finalizeLoad like the ELF &...

...color here. Jim? > > My lame idea would be: > > ExecutionEngine -> JIT > ExecutionEngine -> JIT/Legacy > ExecutionEngine/MCJIT -> JIT/MC > ExecutionEngine/OProfileJIT -> JIT/OProfile > ExecutionEngine/IntelJITEvenst -> JIT/IntelJITEvents > ExecutionEngine/RuntimeDyld -> JIT/RuntimeDyld > So long as we have the interpreter, we should keep the ExecutionEngine abstraction around. That said, I'd personally like to kill the interpreter… Eventually, lots of this can (and should) be simplified and flattened as the obsolete bits get deleted (legacy JIT and...

...onsistent though: What address they return depends on what the caller (relocation logic) wants to do to fix up the stub. That could be modifying operands in the stub, or it could be tagging an extra absolute address field after the stub. Hopefully we can start to clean this stuff up as we move to a RuntimeDyld-class-per-target setup. Cheers, Lang. On Tue, Nov 4, 2014 at 8:23 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > I've found it. Host-endianness isn't accounted for when emitting the > instructions in the ARM, AArch64, and Mips paths of > RuntimeDyldImpl::crea...

...unction<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 RuntimeDyld::LoadedObjectInfo, as this is what listeners expect: $ grep -h -r -A 1 "NotifyObjectEmitted(" ./include/llvm/ExecutionEngine/JITEventListener.h   virtual void NotifyObjectEmitt...

...mbols.so - or $ clang++ -lSymbols symbols.cxx && ./a.out Compiled it's happy: the weak symbol used in main gets resolved to be the one in the binary for both references. That's the behavior I'd expect. The JIT OTOH is deciding that it shall use the local version of the symbol; RuntimeDyld::getSymbol() doesn't care about the fact that the symbol is weak and has an existing occurrence. For weak symbols from a different module, RuntimeDyld would use resolveExternalSymbols() and all would be good - but here this doesn't happen. IIUC, RuntimeDyld::getSymbol() really needs to ch...

Hi All Is there any technical reason why we can’t or shouldn’t have RuntimeDyld be able to enumerate all symbols in the dyld? I know elf, mach-o apis have this capability, and I’m reasonably sure coff has support for it as well.

...r(); With this set of functions it attempts to JIT something at least. I run into a segfault, valgrind reports the following: ==27130== Process terminating with default action of signal 11 (SIGSEGV) ==27130== Bad permissions for mapped region at address 0xEAF02F7 ==27130== at 0xEAF031F: llvm::RuntimeDyldELF::resolveX86_64Relocation(llvm::SectionEntry const&, unsigned long, unsigned long, unsigned int, long, unsigned long) (RuntimeDyldELF.cpp:213) ==27130== by 0xEAF260F: llvm::RuntimeDyldELF::resolveRelocation(llvm::SectionEntry const&, unsigned long, unsigned long, unsigned int, long, un...

...ecutionEngine::addGlobalMapping related function to my JIT context, and I create a lambda resolver as such: JITContext::addModule(…) { auto Resolver = createLambdaResolver( [&](const std::string &name) { // look up first in JIT'ed code if (auto sym = findMangledSymbol(name)) { return RuntimeDyld::SymbolInfo(sym.getAddress(), sym.getFlags()); return RuntimeDyld::SymbolInfo(nullptr); } // look up in added globals if (auto addr = getPointerToGlobalMapping(name)) { return RuntimeDyld::SymbolInfo(addr, JITSymbolFlags::Exported); } // finally try to look up existing process symbols, note // th...

.../24/2011 13:23, Jim Grosbach wrote: >> Any progress with this? >> gitorious page shows the last update on Jul 27, 2010. >> > There's basics for an MC JIT implemented now, but it's not yet full featured enough to replace the old JIT. Have a look at ExecutionEnginer/RuntimeDyld and ExecutionEngine/MCJIT. > > It's usable enough for some things; for example, dynamic expression evaluation in lldb. The biggest gaps are more thorough relocation support and lazy compilation. > Does it, or does it plan to write binary PIC code into the continuous memory area w...

Hi Lang, thanks for announcing. Would be great if you could send another short notice as soon as the actual patch exists. Best, Stefan Am 24.05.16 um 23:06 schrieb Lang Hames via llvm-dev: > Hi All, > > I'm going to be making some API breaking changes to the ORC APIs, and > to the RuntimeDyld class (which underlies MCJIT). The changes may > affect MCJIT clients but are unlikely to. Where they do the fixes are > likely to be trivial. ORC clients will be affected, but the fixes > should also be straightforward. > > I have three upcoming changes in mind: > > 1) Runtime...

...Jim Grosbach wrote: >>> Any progress with this? >>> gitorious page shows the last update on Jul 27, 2010. >>> >> There's basics for an MC JIT implemented now, but it's not yet full featured enough to replace the old JIT. Have a look at ExecutionEnginer/RuntimeDyld and ExecutionEngine/MCJIT. >> >> It's usable enough for some things; for example, dynamic expression evaluation in lldb. The biggest gaps are more thorough relocation support and lazy compilation. >> > > Does it, or does it plan to write binary PIC code into the con...