[LLVMdev] Trouble Resolving Objective-C Symbols in lli
Ralph Corderoy
ralph at inputplus.co.uk
Fri Jul 20 04:22:29 PDT 2007
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.
More information about the llvm-dev
mailing list