search for: dlsym

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 have magic meaning. This > itself isn't a problem, the problem is that they are absol...

I am trying to install dotnet20 in 0.9.58 with sh winetricks dotnet20 It hangs after extracting a file with sh winetricks dotnet20 Using system libcrypto, version 90709F DLSYM: Failed to resolve FIPS_mode_set: 127 DLSYM: Failed to resolve FIPS_mode: 127 DLSYM: Failed to resolve SHA256: 127 DLSYM: Failed to resolve SHA512: 127 DLSYM: Failed to resolve EVP_sha224: 127 DLSYM: Failed to resolve EVP_sha256: 127 DLSYM: Failed to resolve EVP_sha384: 127 DLSYM: Failed to...

Hi Reid, > > if ((err = dlerror())) { > > error("earlier undetected dlerror: %s\n", err); > > } > > p = dlsym(handle, sym); > > if ((err = dlerror())) { > > error("dlsym failed: %s\n", err); > > } > > No, you're not missing anything. The correct way to check for errors > is with dlerror. > > Please note that on the "trunk" revision...

...ious -ldl options here] When using ‘CFLAGS="-fsanitize=address"’ this succeeds even if no dl libraries are used at all, since it appears that using this option causes dlopen to be included in the final binary implicitly. This causes configure to set DL_LIBS='', but unfortunately dlsym is not included implicitly and so linking fails. Although I believe this is a bug in GCC 9, as a workaround use dlsym as the sentinel function instead. The new output from ‘./configure CFLAGS="-fsanitize=address"’ is: checking for library containing dlsym... -ldl [...] checking f...

Hi Ralph, On Fri, 2007-07-20 at 12:22 +0100, Ralph Corderoy wrote: > Hi Reid, > > > > if ((err = dlerror())) { > > > error("earlier undetected dlerror: %s\n", err); > > > } > > > p = dlsym(handle, sym); > > > if ((err = dlerror())) { > > > error("dlsym failed: %s\n", err); > > > } > > > > No, you're not missing anything. The correct way to check for errors > > is with dlerror. > > > > Please not...

I am guessing that sanitizers are not supported with static linking. The AddressSanitizer document says so explicitly but the others do not. Yet the interceptors use dlsym to set up certain system calls, so by definition they can't support static linking. Given that sanitizers won't work with static linking, why are static libraries created for them? Should there be an error check in the interceptor code for dlsym returning nullptr? I just spent a bunch of...

Hi Ralph, On Fri, 2007-07-20 at 10:38 +0100, Ralph Corderoy wrote: > Hi Chris, > I could be missing something, but shouldn't the use of dlsym() be > > char *err; > void *p; > > if ((err = dlerror())) { > error("earlier undetected dlerror: %s\n", err); > } > p = dlsym(handle, sym); > if ((err = dlerror())) { > error("dlsym failed: %s\n", err); >...

...t; 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 a problem, the problem is that they are absolute symbols (which is...

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

Hi Vania, If I understood correctly, you have an executable, which is JITing code that has dependencies on the symbols of entire executable. In case dlsym cannot find this symbol, try to link your executable with -rdynamic (gcc) or --export-dynamic (ld): -rdynamic Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to th...

...alled the ExecutionEngine. Of course when running we get the error message LLVM ERROR: Program used external function open_device which could not be resolved! How can we dynamically resolve such external addresses ? We have seen in the documentation llvm is trying to link unresolved symbols with dlsym(). In this case it fails. Is there a hook we can plug in the execution engine so that we control ourselves the resolution of external symbols after dlsym() has failed. We still want to try dlsym() first and only when it fails then take control. We do not see this in the execution engine interfac...

Hi Jan, In gcc for Linux, you have the -rdynamic option that allows an executable to dlsym its symbols. Since llvm use dlsym to find the symbols, you could try with this option. That's what I did. And don't forget to use the C++ name if you compile with C++. Cheers, Nicolas Jan Rehders wrote: > Hi, > > I was able to try this on linux again. Unfortunately it doesn't...

Hi Nate. I've noticed that when I hardcode ExecutionEngine::areDlsymStubsEnabled() to always return false, check-lit still passes. I'm working on fixing a couple bugs in the JIT that involve changing how stubs are handled. I'm being careful around dlsym stubs, but I'm not perfect and may make a mistake. I'd really appreciate if you could add some te...

The DynamicLibrary.cpp code is written and I believe it to be complete, but it hasn't been tested much (at all). llvm-ld uses it to load its plug-in optimization module. The implementation will use ltdl library if its available, otherwise it tries to use dlopen/dlsym if they are available, otherwise you get a compile time warning and (void*)0 if you try to look up a symbol. I'm not sure about the libtool implementation but it does more than just accommodate the platform differences for the interface function names. It also makes sure that platform requirem...

On 03/13/2013 11:01 AM, Dmitry Mikushin wrote: > Hi Vania, > > If I understood correctly, you have an executable, which is JITing > code that has dependencies on the symbols of entire executable. In > case dlsym cannot find this symbol, try to link your executable with > -rdynamic (gcc) or --export-dynamic (ld): > > -rdynamic > Pass the flag -export-dynamic to the ELF linker, on targets > that > support it. This instructs the linker to add all symbols, >...

Hi all, There are symbols in libgcc (and compiler-rt) that JIT-compiled modules may need. These are currently linked correctly because lli and friends are linked against libgcc_s.so (i.e. shared library version of libgcc, so dlopen/dlsym works). However if a consumer links statically, dlsym won't find all compiler required functions (only the ones that were required by the JIT-compiler itself will be linked). So the question is, do we want to support users of the MCJIT linking statically to libgcc/compiler-rt? Or explicitly n...

Hi, I was able to try this on linux again. Unfortunately it doesn't work at all (neither using runFunction nor a CallInst). It simply says function called get5 not known. Calling printf the same way works, though. On linux the function is exported as "get5" from the executable while it is called "_get5" on OS X. I could not spot any other differences.. any

On Tue, Mar 12, 2013 at 9:19 AM, Renato Golin <renato.golin at linaro.org>wrote: > On 12 March 2013 15:28, Hal Finkel <hfinkel at anl.gov> wrote: > >> Can't we just paste in a RNG so that we'll get the same output on all >> systems (and can still use the reference output)? >> > > We can, though other tests suffer from the same issue. Would be good

...ncer wrote: > The DynamicLibrary.cpp code is written and I believe it to be complete, > but it hasn't been tested much (at all). llvm-ld uses it to load its > plug-in optimization module. The implementation will use ltdl library > if its available, otherwise it tries to use dlopen/dlsym if they are > available, otherwise you get a compile time warning and (void*)0 if you > try to look up a symbol. Okay, interesting. How hard would it be to replace the DynamicLinker.cpp functionality with your code? > I'm not sure about the libtool implementation but it does more th...

...PC backend on the test > > suite. > > > > The known problem is that the JIT seems unable to resolve calls to > > external functions that start with "__", such as __eprintf, __moddi3, etc. > > This appears to be something funny in the darwin implementation of dlsym > > (returning null for symbols that are valid if they start with __). If > > anyone has any ideas of how to make this work, we would love to hear them. > > :) > > > > -Chris > > ______________________________________________________________________ > _____...