search for: getpointertonamedfunction

...et-up. [----------] 3 tests from MultiJitTest [ RUN ] MultiJitTest.EagerMode [ OK ] MultiJitTest.EagerMode (10 ms) [ RUN ] MultiJitTest.LazyMode [ OK ] MultiJitTest.LazyMode (0 ms) [ RUN ] MultiJitTest.JitPool MultiJITTest.cpp:164: Failure Value of: (intptr_t)&getPointerToNamedFunction Actual: 4478936 Expected: (intptr_t)getPointerToNamedFunction("getPointerToNamedFunction") Which is: 1744875364 [ FAILED ] MultiJitTest.JitPool (30 ms) [----------] 3 tests from MultiJitTest (60 ms total) I wouldn't imagine that this is 'normal', right? Otherw...

...Enginetests, > JITTests, SupportTests, UtilsTests and VMCoreTests). All of them pass > without any problem, except for JITTests which fails on the > MultiJitTest.JitPool test: > [ RUN      ] MultiJitTest.JitPool > > MultiJITTest.cpp:164: Failure > > Value of: (intptr_t)&getPointerToNamedFunction > >   Actual: 4478936 > > Expected: (intptr_t)getPointerToNamedFunction("getPointerToNamedFunction") > > Which is: 1744875364 > > [  FAILED  ] MultiJitTest.JitPool (30 ms) > > [----------] 3 tests from MultiJitTest (60 ms total) > I wouldn’t imagine that...

.../Foundation.framework/Foundation | > grep .objc_class_name_NSAutoreleasePool > > 00000000 A .objc_class_name_NSAutoreleasePool Ok, as you figured out, you do need to tell lli explicitly what frameworks to load. Once you have that, you are hitting another problem. Specifically, the JIT::getPointerToNamedFunction method in lib/ExecutionEngine/JIT/Intercept.cpp just does a dlsym on missing symbols. If dlsym returns null, you get the error message. The problem here is that .objc_class_name_* are special symbols that are used by the objc linker support and they have magic meaning. This itself isn't...

Hi there, I'm trying to run trivial Objective-C code that uses the Foundation framework under MacOS X in lli. It seems that the code will compile and run using llc, however fails to work in lli. SimpleFoundation.m: ---- #import <Foundation/Foundation.h> int main (int argc, const char * argv[]) { NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; // insert code

...LazyFunctionCreator); which works fine with the JIT. However, MCJIT insists on resolving unknown symbols by searching them outdoors and seems oblivious of the existence of MyLazyFunctionCreator. Is this a bug? Is there a workaround, other than subclassing JITMemoryManager and implementing my own getPointerToNamedFunction? (which would make the existence of ExecutionEngine::InstallLazyFunctionCreator pointless.)

...se virtual uint8_t *allocateDataSection(uintptr_t Size, unsigned Alignment, unsigned SectionID) { return mgr()->allocateDataSection(Size, Alignment, SectionID); } #endif virtual void *getPointerToNamedFunction(const std::string &Name, bool AbortOnFailure=true) { return mgr()->getPointerToNamedFunction(Name, AbortOnFailure); } #if HAVE_LLVM == 0x0303 virtual bool applyPermissions(std::string *ErrMsg = 0) { return mgr()->...

...ster all subtle reasons - code alignment/prologue ?) A mutex on the StubToResolverMap should prevent any possible race conditions. Every object (Emitter, Resolver, ResolverState) have now a private member instance of JIT (JIT *Jit). The bugpoint tool is using a extern 'C' function : "getPointerToNamedFunction" to get native pointer on function. This function used the TheJit static pointer. To keep alive this functionality, I have added a static SmallVector<JIT*> JitPool (with its mutex JitPoolLock), which keep pointers of available JIT instance. A new static method on JIT object "getPoin...

...ologue > ?) > A mutex on the StubToResolverMap should prevent any possible race > conditions. > > Every object (Emitter, Resolver, ResolverState) have now a private member > instance of JIT (JIT *Jit). > > The bugpoint tool is using a extern 'C' function : > "getPointerToNamedFunction" to get native pointer on function. This function > used the TheJit static pointer. To keep alive this functionality, I have > added a static SmallVector<JIT*> JitPool (with its mutex JitPoolLock), which > keep pointers of available JIT instance. A new static method on JIT objec...

...ithin LLVM that are using the DynamicLibrary stuff, but there's no telling what various LLVM consumers may be using it for. The "stat" symbols shouldn't be exposed the way they are in the old JIT memory manager location. It's not clear to me why that didn't happen inside getPointerToNamedFunction there. Is there a reason not to just do this kind of handling in RTDyldMemoryManager/DefaultJITMemoryManager::getPointerToNamedFunction()? -Andy -----Original Message----- From: James Lyon [mailto:jameslyon0 at gmail.com] Sent: Monday, November 11, 2013 11:13 AM To: Kaylor, Andrew; LLVM Dev Sub...

.... > > 3. Whenever the user program calls PerformCustomCallback with > appropriate arguments, lli should experience a call to one of the > registered callbacks. > > > > *Methodology:* > > In JIT, the external symbols are resolved during the call to void > *JIT::getPointerToNamedFunction(const std::string &Name, bool > AbortOnFailure). So, the hypercall resolution can be done here. > > In MCJIT, during finalizeObject(), all the symbol relocations are > finalized. In the Memory Managers, the external symbols are resolved. So, > the hypercall resolution can be done...

...StubToResolverMap should prevent any possible race > > conditions. > > > > Every object (Emitter, Resolver, ResolverState) have now a private member > > instance of JIT (JIT *Jit). > > > > The bugpoint tool is using a extern 'C' function : > > "getPointerToNamedFunction" to get native pointer on function. This > function > > used the TheJit static pointer. To keep alive this functionality, I have > > added a static SmallVector<JIT*> JitPool (with its mutex JitPoolLock), > which > > keep pointers of available JIT instance. A new s...

...M that are using the DynamicLibrary stuff, but there's no telling what various LLVM consumers may be using it for. > > The "stat" symbols shouldn't be exposed the way they are in the old JIT memory manager location. It's not clear to me why that didn't happen inside getPointerToNamedFunction there. > > Is there a reason not to just do this kind of handling in RTDyldMemoryManager/DefaultJITMemoryManager::getPointerToNamedFunction()? > > -Andy > > -----Original Message----- > From: James Lyon [mailto:jameslyon0 at gmail.com] > Sent: Monday, November 11, 2013 11:13...

...find much about how the JIT resolves symbols, so can somebody answer a few questions for me? 1. Will the symbols from a dlopen'd library with RTLD_GLOBAL be available? In this case I can manually dlopen the libraries prior to the JIT run. 2. Can I derive from ExecutionEngine and override the getPointerToNamedFunction method? If so, does this just return the C/ABI pointer to the function? What is the equivalent for data variables? 3. Is the same basic model available on Windows using DLLs? I really don't have any experience there yet. -- edA-qa mort-ora-y -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --...

...*allocateDataSection(uintptr_t Size, > unsigned Alignment, > unsigned SectionID) { > return mgr()->allocateDataSection(Size, Alignment, SectionID); > } > #endif > virtual void *getPointerToNamedFunction(const std::string &Name, > bool AbortOnFailure=true) { > return mgr()->getPointerToNamedFunction(Name, AbortOnFailure); > } > #if HAVE_LLVM == 0x0303 > virtual bool applyPermissions(std::string *ErrMsg = 0) { >...

...s fine with the JIT. However, MCJIT insists on resolving > unknown symbols by searching them outdoors and seems oblivious of the > existence of MyLazyFunctionCreator. > > Is this a bug? > > Is there a workaround, other than subclassing JITMemoryManager and > implementing my own getPointerToNamedFunction? (which would make the > existence of ExecutionEngine::InstallLazyFunctionCreator pointless.) After working around the issue mentioned above by subclassing JITMemoryManager, I hit another roadblock: Full-featured argument passing not supported yet! UNREACHABLE executed at /home/oscar/dev/llvm/...

Hi, I am using llvm to generate jit code for numerical computation on window 7 64 platform. There is a function call, pow, in the jit code. The problem is that at run time, the pow function call sometimes links to msvcrt.dll, and sometimes to msvcr100.dll. These two calls from two dlls return different results, causing sporadic results. I tried to make the pow function either intrinsic or

...the DynamicLibrary stuff, but there's no telling what various LLVM consumers may be using it for. >>> >>> The "stat" symbols shouldn't be exposed the way they are in the old JIT memory manager location. It's not clear to me why that didn't happen inside getPointerToNamedFunction there. >>> >>> Is there a reason not to just do this kind of handling in RTDyldMemoryManager/DefaultJITMemoryManager::getPointerToNamedFunction()? >>> >>> -Andy >>> >>> -----Original Message----- >>> From: James Lyon [mailto:jameslyon0...

...xing of the various callbacks registered with them. 3. Whenever the user program calls PerformCustomCallback with appropriate arguments, lli should experience a call to one of the registered callbacks. *Methodology:* In JIT, the external symbols are resolved during the call to void *JIT::getPointerToNamedFunction(const std::string &Name, bool AbortOnFailure). So, the hypercall resolution can be done here. In MCJIT, during finalizeObject(), all the symbol relocations are finalized. In the Memory Managers, the external symbols are resolved. So, the hypercall resolution can be done in LinkingMemoryManager...

...re using the DynamicLibrary stuff, but there's no telling what various LLVM consumers may be using it for. >> >> The "stat" symbols shouldn't be exposed the way they are in the old JIT memory manager location. It's not clear to me why that didn't happen inside getPointerToNamedFunction there. >> >> Is there a reason not to just do this kind of handling in RTDyldMemoryManager/DefaultJITMemoryManager::getPointerToNamedFunction()? >> >> -Andy >> >> -----Original Message----- >> From: James Lyon [mailto:jameslyon0 at gmail.com] >> Sent:...

...tptr_t Size, >> unsigned Alignment, >> unsigned SectionID) { >> return mgr()->allocateDataSection(Size, Alignment, SectionID); >> } >> #endif >> virtual void *getPointerToNamedFunction(const std::string &Name, >> bool AbortOnFailure=true) { >> return mgr()->getPointerToNamedFunction(Name, AbortOnFailure); >> } >> #if HAVE_LLVM == 0x0303 >> virtual bool applyPermissions(std::string...