Ralph Corderoy
2007-Jul-20 09:38 UTC
[LLVMdev] Trouble Resolving Objective-C Symbols in lli
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 absolute symbols > (which is why nm prints 'A' for the symbol) and their absolute value > is 0. When dlsym correctly returns the address of this symbol, it > returns a null pointer (which is the address of the symbol) and lli > aborts because it thinks dlsym returned failure. > > After consulting with our dynamic linker guru, I don't think there is > a wonderful clean way to do this.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); } return p; The authors of dlsym() realised the return value was overloaded AFAICS. Cheers, Ralph.
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); > } > > return p; > > The authors of dlsym() realised the return value was overloaded AFAICS.No, 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 into the native executable, but only from an actually loaded shared object. Reid.> > Cheers, > > > Ralph. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Ralph Corderoy
2007-Jul-20 11:22 UTC
[LLVMdev] Trouble Resolving Objective-C Symbols in lli
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 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-167 says: Function: lt_ptr lt_dlsym(lt_dlhandle handle, const char *name) Return the address in the module handle, where the symbol given by the null-terminated string name is loaded. If the symbol cannot be found, NULL is returned. And lt_dlerror() also appears to have the same behaviour as its non-lt_ counterpart, so you'd think you'd have to do the same as above; use lt_dlerror(). However, it appears things like libtool's static lt_ptr sys_dl_sym (loader_data, module, symbol) lt_user_data loader_data; lt_module module; const char *symbol; { lt_ptr address = dlsym (module, symbol); if (!address) { LT_DLMUTEX_SETERROR (DLERROR (SYMBOL_NOT_FOUND)); } return address; } break the ability to detect an undefined symbol versus a symbol with a value of 0 because it sets the lt_dlerror() whenever dlsym() returns 0. Perhaps a bug in libtool, I was looking at 1.5.6, but it's a twisty maze and I could have taken a wrong turn. It's clear dlsym() gives the required functionality; the layers of wrapping on top of it present a broken interface. Cheers, Ralph.
Chris Lattner
2007-Jul-20 15:14 UTC
[LLVMdev] Trouble Resolving Objective-C Symbols in lli
On Fri, 20 Jul 2007, Ralph Corderoy wrote:> I could be missing something, but shouldn't the use of dlsym() be > The authors of dlsym() realised the return value was overloaded AFAICS.Yep, patches welcome :) -Chris -- http://nondot.org/sabre/ http://llvm.org/
Chris / Ralph / Others, On Fri, 2007-07-20 at 08:14 -0700, Chris Lattner wrote:> On Fri, 20 Jul 2007, Ralph Corderoy wrote: > > I could be missing something, but shouldn't the use of dlsym() be > > The authors of dlsym() realised the return value was overloaded AFAICS. > > Yep, patches welcome :) > > -Chris >I don't recall who originally asked for help with this, but here's a patch that could fix it. Please try this and let me know if it works. If so, I'll commit it. The patch isn't complete (it should do something in the error condition) but it should allow you to find symbols whose address is 0. Reid. Index: DynamicLibrary.cpp ==================================================================--- DynamicLibrary.cpp (revision 40112) +++ DynamicLibrary.cpp (working copy) @@ -130,11 +130,19 @@ if (I != g_symbols.end()) return I->second; + // Clear the error status of the ltdl library + lt_dlerror(); + // Now search the libraries. for (std::vector<lt_dlhandle>::iterator I = OpenedHandles.begin(), E = OpenedHandles.end(); I != E; ++I) { lt_ptr ptr = lt_dlsym(*I, symbolName); - if (ptr) + + // Get the error for the lt_dlsym call. If there was no error and the result + // from lt_dlsym was 0 then 0 is the address of the symbol, not an + // indication that it couldn't be found. + const char *errmsg = lt_dlerror(); + if (ptr || !errmsg) return ptr; } Please apply to lib/System/DynamicLibrary.cpp. -------------- next part -------------- A non-text attachment was scrubbed... Name: DL.patch Type: text/x-patch Size: 817 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070720/5ddddf80/attachment.bin>
Maybe Matching Threads
- [LLVMdev] Trouble Resolving Objective-C Symbols in lli
- [LLVMdev] Trouble Resolving Objective-C Symbols in lli
- [LLVMdev] Trouble Resolving Objective-C Symbols in lli
- [LLVMdev] Trouble Resolving Objective-C Symbols in lli
- [LLVMdev] Trouble Resolving Objective-C Symbols in lli