search for: searchforaddressofsymbol

I've finally managed to extract from Kaleidoscope one particular thing that it seems to me should be working and isn't. Given the global declaration extern "C" void foo() {} within the same program I have RTDyldMemoryManager::getSymbolAddressInProcess("foo") And it's returning null. (LLVM 3.8, Windows 7 x64.) What am I missing? -------------- next part

...; > > Ahh -- I see the problem. The DynamicLibrarySearchGenerator is using the getAddressOfSymbol method, which (under the hood) is basically issuing an appropriate dlsym lookup, and that does not find explicitly added symbols. To find explicitly added symbols you need to call DynamicLibrary::SearchForAddressOfSymbol instead, but unfortunately that method's behavior is not a good fit for what DynamicLibrarySearchGenerator is trying to do. > > There are two ways you could tackle this: > (1) Write your own generator that calls sys::DynamicLibrary::SearchforAddressOfSymbol, or > (2) Add the symbols...

Hi, Would it be possible to make the following slight change to ExecutionEngine::create()? I would like to be able to disable the automatic enumeration of loaded modules, and the subsequent searching for undefined symbols (using SearchForAddressOfSymbol). I propose adding an extra parameter to the function definition, defaulting to true. static ExecutionEngine *create(ModuleProvider *MP, bool ForceInterpreter = false, std::string *ErrorStr = 0, b...

...c:/projects/src/llvm-1/llvm/lib/System/DynamicLibrary.cpp:25: c:/projects/src/llvm-1/llvm/lib/System/win32/DynamicLibrary.cpp:22: warning: ignoring #pragma comment c:/projects/src/llvm-1/llvm/lib/System/win32/DynamicLibrary.cpp: In static member function `static void* llvm::sys::DynamicLibrary::SearchForAddressOfSymbol(const char*)': c:/projects/src/llvm-1/llvm/lib/System/win32/DynamicLibrary.cpp:114: error: invalid conversion from `int (*)()' to `void*' c:/projects/src/llvm-1/llvm/lib/System/win32/DynamicLibrary.cpp: In member function `void* llvm::sys::DynamicLibrary::GetAddressOfSymbol(const char...

Hi Lang, On Tue, 13 Aug 2019 at 22:03, Lang Hames <lhames at gmail.com> wrote: > When you say your code is not getting optimized, do you mean that IR optimizations are not being applied, or that codegen optimizations are not being applied? > > What do you see if you dump the modules before/after running the pass manager on them, like this: > > dbgs() << "Before

Hello, I have a bytecode doing 64 bits division and on Mingw32/x86, lli complains it cannot resolve __udivdi3 when running it. Those symbols are all part of libgcc and all present in lli, but they cannot be found by SearchForAddressOfSymbol (not in any DLL). To workaround that, I explicitely define them in Win32/DynamicLibrary.inc if the current target is Mingw32 (patch attached). Anybody had this problem before ? Is this a proper fix ? Thanks, Julien -- Julien Lerouge PGP Key Id: 0xB1964A62 PGP Fingerprint: 392D 4BAD DB8B CE7F 4E...

On Jul 22, 2009, at 5:23 PM, Chris Lattner wrote: > > On Jul 22, 2009, at 1:32 PM, Dan Gohman wrote: > >>>> >>>> - A null pointer is associated with no addresses. >>>> >>> >>> A null pointer in address space 0. >> >> I'm not fond of weird address-space semantics, but for consistency >> with what the optimizer is

...3 PM, Rob Grapes wrote: > Hi, > > Would it be possible to make the following slight change to > ExecutionEngine::create()? > > I would like to be able to disable the automatic enumeration of > loaded modules, and the subsequent searching for undefined symbols > (using SearchForAddressOfSymbol). > > I propose adding an extra parameter to the function definition, > defaulting to true. I'd rather not. The current API is messy enough already. Is there not another way to solve the problem? Evan > > static ExecutionEngine *create(ModuleProvider *MP, >...

...you're not missing anything. The correct way to check for errors is with dlerror. Please note that on the "trunk" revision of llvm (soon to be 2.1), and I think also 2.0, there are 0 calls to dlsym in the Intercept.cpp. They have been replaced with a call to sys::DynamicLibrary::SearchForAddressOfSymbol(NameStr) Which is part of LLVM's lib/System package. That package implements this using the libtool "ltdl" library, which presumably gets this right in an operating system correct way. One of the issues with this is that on some systems you can't get the symbols that were linked...

...gt;> Hi, >> >> Would it be possible to make the following slight change to >> ExecutionEngine::create()? >> >> I would like to be able to disable the automatic enumeration of >> loaded modules, and the subsequent searching for undefined symbols >> (using SearchForAddressOfSymbol). >> >> I propose adding an extra parameter to the function definition, >> defaulting to true. > > I'd rather not. The current API is messy enough already. Is there not > another way to solve the problem? > > Evan > >> >>  static ExecutionEngine *...

...lvm/lib/System/DynamicLibrary.cpp:25: > c:/projects/src/llvm-1/llvm/lib/System/win32/DynamicLibrary.cpp:22: warning: > ignoring #pragma comment > c:/projects/src/llvm-1/llvm/lib/System/win32/DynamicLibrary.cpp: In static > member function `static void* > llvm::sys::DynamicLibrary::SearchForAddressOfSymbol(const char*)': > c:/projects/src/llvm-1/llvm/lib/System/win32/DynamicLibrary.cpp:114: error: > invalid conversion from `int (*)()' to `void*' > c:/projects/src/llvm-1/llvm/lib/System/win32/DynamicLibrary.cpp: In member > function `void* llvm::sys::DynamicLibrary::GetAddres...

...DynamicLibrary.cpp:25: >>c:/projects/src/llvm-1/llvm/lib/System/win32/DynamicLibrary.cpp:22: warning: >>ignoring #pragma comment >>c:/projects/src/llvm-1/llvm/lib/System/win32/DynamicLibrary.cpp: In static >>member function `static void* >>llvm::sys::DynamicLibrary::SearchForAddressOfSymbol(const char*)': >>c:/projects/src/llvm-1/llvm/lib/System/win32/DynamicLibrary.cpp:114: error: >>invalid conversion from `int (*)()' to `void*' >>c:/projects/src/llvm-1/llvm/lib/System/win32/DynamicLibrary.cpp: In member >>function `void* llvm::sys::DynamicLibrar...

Unless I'm missing something, indeed addGlobalMapping should not work with MCJIT. MCJIT does not consult EEState.getGlobalAddressMap when resolving symbols. Instead it uses RTDyldMemoryManager::getSymbolAddress which checks with DynamicLibrary::SearchForAddressOfSymbol, so Andy's suggestion of DynamicLibrary::addSymbol is better as it should work with both JIT and MCJIT. Another options is to use the LazyFunctionCreator which is implemented in both JIT and MCJIT. Andy - MCJIT::getPointerToFunction does call EE:addGlobalMapping - however EEState.getGlobalAdd...

Hi Chris, > 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

Hi Andrew, I used the latest code from trunk. GlobalSymbolTable is being used in MCJIT. I guess it wasn't clear from the proposal that the user program will be modified to indicate that the callback should happen at that point in the code. The objective is to call some of the functions which belong to lli or the ExecutionEngine. Thanks, Sumeeth On Fri, Nov 1, 2013 at 5:40 PM, Kaylor,

...es the LLVMJIT library the JITMemoryManager hack is always there (subject to being dropped by ld?) so these symbols are actually exposed globally. As I said, I basically just borrowed from the existing code and added the functions which won't work without glibc on ARM. sys::DynamicLibrary::SearchForAddressOfSymbol only seems to be used by stuff under lib/ExecutionEngine, so making that find functions which are expected to be in libc during normal linking doesn't seem unreasonable. James > > -Andy > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounc...

...he correct way to check for errors > is with dlerror. > > Please note that on the "trunk" revision of llvm (soon to be 2.1), and > I think also 2.0, there are 0 calls to dlsym in the Intercept.cpp. > They have been replaced with a call to > > sys::DynamicLibrary::SearchForAddressOfSymbol(NameStr) > > Which is part of LLVM's lib/System package. That package implements > this using the libtool "ltdl" library, which presumably gets this > right in an operating system correct way. Presumably? http://www.gnu.org/software/libtool/manual.html#index-lt_005fdlsym...

...gt;> Hi, >> >> Would it be possible to make the following slight change to >> ExecutionEngine::create()? >> >> I would like to be able to disable the automatic enumeration of >> loaded modules, and the subsequent searching for undefined symbols >> (using SearchForAddressOfSymbol). >> >> I propose adding an extra parameter to the function definition, >> defaulting to true. > > I'd rather not. The current API is messy enough already. Is there not > another way to solve the problem? > > Evan > >> >>  static ExecutionEngine *...

...he JIT engine by calling the JIT::getPointerToFunction() method. If the JIT engine isn't able to associate the function with an existing known function and can't JIT it, it will attempt to lookup the function by name. One of the ways it attempts to do so is by calling sys::DynamicLibrary::SearchForAddressOfSymbol() which will return the address of the function in the current process if such an address is available. I believe that this basic functionality has be in place for quite some time. It has, however, been changed recently so that the implementation of this external symbol resolution is now handled...

...n from the JIT engine by calling the JIT::getPointerToFunction() method. If the JIT engine isn’t able to associate the function with an existing known function and can’t JIT it, it will attempt to lookup the function by name. One of the ways it attempts to do so is by calling sys::DynamicLibrary::SearchForAddressOfSymbol() which will return the address of the function in the current process if such an address is available. > > I believe that this basic functionality has be in place for quite some time. It has, however, been changed recently so that the implementation of this external symbol resolution is n...