[LLVMdev] Trouble Resolving Objective-C Symbols in lli

[Ralph Corderoy]

Hi Reid,

> >     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 is a twisty mess. Function pointers in structures? Who'd ever do
> THAT? :)

If I know the right way to use dlsym() I can probably handle a function
pointer or two.  ;-)

> However, I don't think the code above is necessarily wrong. If you get
> an address back, there's no error (dlerror only reports and error when
> dlsym returns 0).

If you mean sys_dl_sym() then I think you've taken the wrong twisty
passage.  It seems broken to me.  It sets its internal error code to
SYMBOL_NOT_FOUND if dlsym() returns 0.  It too should do the double
shuffle with dlerror() to correctly detect a missing symbol but doesn't.
I've mailed the libtool guys to see if they concur.

> I think the entire problem is that the lib/System library is not using
> the lt_dlerror function properly. For example:
> 
>   // 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)
>       return ptr;
>   }
> 
> This needs to call lt_dlerror to clear any previous error, then call
> dl_sym, then call dl_error again to see if there's an error. The lack
> of this checking makes it miss the "return 0 without error" case. 

I agree LLVM has bugs too, and that it needs to do its own
double-shuffle due to the overloaded API originated by dlsym().  But at
the moment libtool dlsym()-wrapper seems buggy and since it sets its
internal error code when it shouldn't, LLVM will see that on the second
call to lt_dlerror().

Cheers,


Ralph.