search for: runtimedyldimpl

...nge below and my reproducable test > case now compiles fine with MCJIT. > > As well, my Common Lisp code base now compiles using MCJIT - that's about > 1,000 > functions at one MCJIT module per function. > > > > In llvm/lib/ExecutionEngine/RuntimeDyld > > Index: RuntimeDyldImpl.h > =================================================================== > --- RuntimeDyldImpl.h (revision 192535) > +++ RuntimeDyldImpl.h (working copy) > @@ -195,7 +195,7 @@ > else if (Arch == Triple::ppc64 || Arch == Triple::ppc64le) > return 44; > else i...

...cific. On akaylor's suggestion I made the change below and my reproducable test case now compiles fine with MCJIT. As well, my Common Lisp code base now compiles using MCJIT - that's about 1,000 functions at one MCJIT module per function. In llvm/lib/ExecutionEngine/RuntimeDyld Index: RuntimeDyldImpl.h =================================================================== --- RuntimeDyldImpl.h (revision 192535) +++ RuntimeDyldImpl.h (working copy) @@ -195,7 +195,7 @@ else if (Arch == Triple::ppc64 || Arch == Triple::ppc64le) return 44; else if (Arch == Triple::x86_64) - retur...

While using MCJIT, when I define a function with name Fn_.._lib_rc-variant.lp0_17_0x706970 ExecutionEngine::getPointerToFunction fails to locate it (returns 0). There is no problem if the function is named Fn_0x706970. There is no problem with those names using the traditional JIT. Is there any special limitation on function names for MC/MCJIT?

...: 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.org/viewvc/llvm-project/llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp?rev=188726&r1=188725&r2=188726&view=diff ==========================================================================...

Hi, There may be two problems with __register_frame usage. However based on http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061768.html I think the existing code is correct for OS-X but likely buggy for Linux and Windows systems. Your crash is on OS-X, right? Anyhow, the first problem is very easy to fix. On Linux and Windows (at least) __register_frame should be called once and not

...cific. On akaylor's suggestion I made the change below and my reproducable test case now compiles fine with MCJIT. As well, my Common Lisp code base now compiles using MCJIT - that's about 1,000 functions at one MCJIT module per function. In llvm/lib/ExecutionEngine/RuntimeDyld Index: RuntimeDyldImpl.h =================================================================== --- RuntimeDyldImpl.h (revision 192535) +++ RuntimeDyldImpl.h (working copy) @@ -195,7 +195,7 @@ else if (Arch == Triple::ppc64 || Arch == Triple::ppc64le) return 44; else if (Arch == Triple::x86_64) - r...

...now compiles fine with MCJIT. > > As well, my Common Lisp code base now compiles using MCJIT - that's > about 1,000 > functions at one MCJIT module per function. > > > > In llvm/lib/ExecutionEngine/RuntimeDyld > > Index: RuntimeDyldImpl.h > =================================================================== > --- RuntimeDyldImpl.h   (revision 192535) > +++ RuntimeDyldImpl.h   (working copy) > @@ -195,7 +195,7 @@ >      else if (Arch == Triple::ppc64 || Arch == Triple::ppc64le) >        ret...

Hi Lang, Can you please let me know you think it would be right to modify RuntimeDyldImpl::resolveExternalSymbols to allow resolvers to return 0 addresses? Something like this would be ideal for me: void RuntimeDyldImpl::resolveExternalSymbols() { while (!ExternalSymbolRelocations.empty()) { StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin(); Str...

...es with characters outside the acceptable range of the object file format in use (ELF, in my case) are mangled, so this name: Fn_.._lib_rc-variant.lp0_17_0x706970 becomes this: Fn_.._lib_rc_2D_variant.lp0_17_0x706970 > When you call getPointerToFunction in MCJIT, it will ultimately call > RuntimeDyldImpl::getSymbolLoadAddress to look the name up in a table > of known function names. That table gets built from the emitted object > image during the RuntimeDyldImpl::loadObject call. If you set a > breakpoint in that function you can see all the symbol names that get > processed and it will...

...relocations in the client is via NotifyLoadedFtor notifications but I couldn't find a way of blocking a relocation resolution. One way to achieve that is to change the Resolver::findSymbol api to allow clients to indicate that the relocations for the symbol shouldn't be resolved and update RuntimeDyldImpl::resolveExternalSymbols accordingly. Would this be a reasonable approach? Thanks, Eugene -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150624/4c4e0f4c/attachment.html>

...tion(llvm::SectionEntry const&, unsigned long, unsigned long, unsigned int, long, unsigned long) (RuntimeDyldELF.cpp:798) ==27130== by 0xEAF258F: llvm::RuntimeDyldELF::resolveRelocation(llvm::RelocationEntry const&, unsigned long) (RuntimeDyldELF.cpp:787) ==27130== by 0xEAE7C67: llvm::RuntimeDyldImpl::resolveRelocationList(llvm::SmallVector<llvm::RelocationEntry, 64u> const&, unsigned long) (RuntimeDyld.cpp:462) ==27130== by 0xEAE543C: llvm::RuntimeDyldImpl::resolveRelocations() (RuntimeDyld.cpp:51) ==27130== by 0xEAE8236: llvm::RuntimeDyld::resolveRelocations() (RuntimeDyld.cpp...

Hi Lang, Yes, I can return a non-zero marker value. Are you ok with this version? void RuntimeDyldImpl::resolveExternalSymbols() { while (!ExternalSymbolRelocations.empty()) { StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin(); StringRef Name = i->first(); if (Name.size() == 0) { // This is an absolute symbol, use an address of zero. DEBUG(d...

...than all the code being loaded. The LLVM side of the call stack looks like this: _wassert(const wchar_t * expr, const wchar_t * filename, unsigned int lineno) Line 369 C llvm::RuntimeDyldCOFFX86_64::resolveRelocation(const llvm::RelocationEntry & RE, unsigned __int64 Value) Line 81 C++ llvm::RuntimeDyldImpl::resolveRelocationList(const llvm::SmallVector<llvm::RelocationEntry,64> & Relocs, unsigned __int64 Value) Line 796 C++ llvm::RuntimeDyldImpl::resolveExternalSymbols() Line 849 C++ llvm::RuntimeDyldImpl::resolveRelocations() Line 95 C++ llvm::RuntimeDyld::resolveRelocations() Line 961 C++...

...unsigned > long, unsigned long, unsigned int, long, unsigned long) > (RuntimeDyldELF.cpp:798) > ==27130== by 0xEAF258F: > llvm::RuntimeDyldELF::resolveRelocation(llvm::RelocationEntry const&, > unsigned long) (RuntimeDyldELF.cpp:787) > ==27130== by 0xEAE7C67: > llvm::RuntimeDyldImpl::resolveRelocationList(llvm::SmallVector<llvm::RelocationEntry, > 64u> const&, unsigned long) (RuntimeDyld.cpp:462) > ==27130== by 0xEAE543C: llvm::RuntimeDyldImpl::resolveRelocations() > (RuntimeDyld.cpp:51) > ==27130== by 0xEAE8236: llvm::RuntimeDyld::resolveRelocation...

> So I'm using "llvm/ExecutionEngine/MCJIT.h" instead of > "llvm/ExecutionEngine/JIT.h", and I've added setUseMCJIT(true) to > EngineBuilder, but what actually happens is: > > LLVM ERROR: Target does not support MC emission! > > Do I need to do anything else? IIRC, this error might be due to not linking against the MCJIT library component. Add the

Hi, I ran into a problem migrating cling (finally!) to MCJIT: When an ("outer") MCJIT's finalization / llvm::RuntimeDyldImpl::resolveExternalSymbols() is called and a symbol is not known, cling can help by loading the suitable library and providing the symbol. It compiles the relevant C++ header as part of loading the library. This compilation emits symbols through the MCJIT. That "inner" MCJIT'ing then ne...

...edAnalysis() / removeDeadPasses(). For 10k iterations, the test took about 12.6s, or 1.26ms per module, so there's definitely some slowdown happening. Looking at the profiling output, it looks like the main difference is the appearance of MCJIT::finalizeLoadedModules(), which ultimately calls RuntimeDyldImpl::resolveRelocations() and SectionMemoryManager::applyMemoryGroupPermissions(), both of which iterate over all memory sections leading to quadratic overhead. I'm not sure how easy it would be, but it seems like there could be single-module variants of these apis that could cut down on the overh...

...es(). > > For 10k iterations, the test took about 12.6s, or 1.26ms per module, so > there's definitely some slowdown happening. Looking at the profiling > output, it looks like the main difference is the appearance of > MCJIT::finalizeLoadedModules(), which ultimately calls > RuntimeDyldImpl::resolveRelocations() and > SectionMemoryManager::applyMemoryGroupPermissions(), both of which iterate > over all memory sections leading to quadratic overhead. I'm not sure how > easy it would be, but it seems like there could be single-module variants > of these apis that could c...

Hi Óscar, I'm not aware of any intentional function name limitations with MCJIT. It's entirely possible that something somewhere is rejecting the name for one reason or another (intentionally or otherwise). When you call getPointerToFunction in MCJIT, it will ultimately call RuntimeDyldImpl::getSymbolLoadAddress to look the name up in a table of known function names. That table gets built from the emitted object image during the RuntimeDyldImpl::loadObject call. If you set a breakpoint in that function you can see all the symbol names that get processed and it will probably tell you...

...ing against that dylib, _ZN11StaticStuffIiE6s is correctly picked up from the dylib. I would expect MCJIT to behave the same. I'll try to fix that myself, but I'd appreciate a hint where to do that. Should I collect linkonce_odr-s and "replace" their emitted code as part of llvm::RuntimeDyldImpl::resolveRelocations()? Or is this just a missing case somewhere? That's e.g. with $ lli --version LLVM (http://llvm.org/): LLVM version 3.6.0svn Optimized build. Built Jan 12 2015 (10:52:59). Default target: x86_64-unknown-linux-gnu Host CPU: corei7-avx Cheers, Axel.