[llvm-commits] [PATCH] Look up symbols in a specific library with DynamicLibrary

Argyrios Kyrtzidis kyrtzidis at apple.com
Thu Aug 11 08:30:24 PDT 2011


On Aug 10, 2011, at 11:52 PM, Jordy Rose wrote:

> 
> On Aug 10, 2011, at 22:08, Jordy Rose wrote:
> 
>> My bad. I kept thinking of this only in Clang terms, where libraries are loaded once by -load way ahead of time. Which is silly. I guess I shouldn't be worrying about the future case where we start paying attention to refcounting libraries.
>> 
>> On the other hand, I'm slightly worried about what happens if we do an infinite number of dlopens without any dlcloses. I would then leave the RTTI but use your API (and make sure to hide the copy constructor). That should make it easy to eventually allow getTemporaryLibrary.
>> 
>>> DynamicLibrary dylib = DynamicLibrary::getPermanentLibrary("mylib.dylib");  // will be added to permanent libraries if it is not already
>>> void *p = dylib.getAddressOfSymbol("mysymbol");
>> 
> 
> Hm...I take it back. It's not possible to do this without using "new" (otherwise you need a copy constructor, which doesn't play well with ref-counted items). Wishing for C++11's move constructors now!
> 
> On the other hand, this looks bad:
> 
>  void *handle = dlopen(filename, [options]);
>  if (OpenedHandles.contains(handle)) {
>    dlclose(handle);
>  }
>  return DynamicLibrary(handle);
> 
> And so does never balancing the dlopen.

Hmm, I still don't see why DynamicLibrary needs to do refcount and not just be a thin wrapper over the handle (constructor will be private and will be only callable by DynamicLibrary's getPermanentLibrary; copy constructor has no issue).
Since the API states that the loading is permanent there's no need for refcounting.

> So, new proposal is to make the constructor load the library permanently for now.
> 
>  DynamicLibrary dylib("mylib.dylib"); // will be added to permanent libraries if not already
>  void *p = ...
> 
> What do you think? It seems like the least of all the evils to me.
> Jordy
> 




More information about the llvm-commits mailing list