[lld] r195307 - [LinkingContext] Limit shared library undefined atoms to be added.

[Nick Kledzik]

On Nov 21, 2013, at 11:04 AM, Shankar Easwaran <shankare at codeaurora.org> wrote:
> On 11/21/2013 12:58 PM, Nick Kledzik wrote:
>> On Nov 21, 2013, at 10:35 AM, Shankar Easwaran <shankare at codeaurora.org> wrote:
>> 
>>> On 11/21/2013 11:30 AM, Nick Kledzik wrote:
>>>> On Nov 20, 2013, at 7:50 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:
>>>> 
>>>> +  /// Add undefined symbols from shared libraries ?
>>>> +  virtual bool addUndefinedAtomsFromSharedLibrary(const SharedLibraryFile *) {
>>>> +    return true;
>>>> +  }
>>>> +
>>>> FYI, MacOSX and iOS use something we call two-level-namespace wherein each imported symbol
>>>> is marked with the dylib it was found in at static link time.  At runtime, the loader (dyld) only looks in
>>>> that symbol in that dylib.  Therefore, there is no need to check undefined symbols in DSOs (dylibs)
>>>> at static link time.
>>> I am trying to understand in a bit more detail here.
>>> 
>>> For example: If I have the below link line
>>> 
>>> ld 1.o libx.so libpthread.a
>>> 
>>> and say libx.so has a undef for pthread_create, and a definition from libpthread.a that resolves pthread_create, does the MacOSX / iOS model export the definition of pthread_create from the executable that was created ?
>> When libx.so was built, it would fail to link unless there was a definition of pthread_create somewhere.  If it was in a dylib (dso), the name of that dylib would be recorded  in libx.so with the undefined symbol for pthread_create.  So when your link line is run, there is no need to load  pthread_create from libpthread.a because libx.so already knows where to find it.
>> 
> Few more questions :-
> 
> Do you also record shared library version information ?
Yes, but Apple never uses shared library versioning.  Our model (to maximize application compatibility) is that we can add APIs to existing shared libraries, but never remove APIs.  If a new incompatible API set is developed, it is put in a a new shared library.

> What if the user dropped in a library like libpthread.so that contained pthread_create ?
I’m not sure what you mean be dropped?  If a new shared library was installed, no existing programs would use it.  They all have their existing two-level-namespace that tells them to find their symbols elsewhere.

> Are the path of the library also recorded ?
Yes.  Mach-O does not just record the leaf file name of shared libraries.  The whole path to it is recorded.  At runtime, dyld just uses that path.  It does not need to search.


> What about weak symbols ? With this I would think weak symbols are also strongly bound ?
Weak is overloaded.  MacOSX/iOS runtime just supports “weak imports” which means a symbol must be found at build time (to record the two-level-namepace info), but  it may be missing at runtime (resolves to NULL).  The main use of this is that apps can be built against the latest OS (really SDK), but can run on older OS versions, as long as it avoids using APIs that don’t exist on that version.


> Is there a way to override runtime behavior like LD_PRELOAD on linux ?
We have something called interposing, where you tell dyld anything being bound to address X should instead get bound to address Y. That is, for instance, how the debugging malloc packages get wired up.  

-Nick