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

[Shankar Easwaran]

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 ? What if the user 
dropped in a library like libpthread.so that contained pthread_create ? 
Are the path of the library also recorded ?

What about weak symbols ? With this I would think weak symbols are also 
strongly bound ?

Is there a way to override runtime behavior like LD_PRELOAD on linux ?

Thanks

Shankar Easwaran

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation