[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