[lld] r195289 - [PECOFF] Do not check if library is already added.

[Nick Kledzik]

On Nov 22, 2013, at 3:40 PM, Rui Ueyama <ruiu at google.com> wrote:

> Thanks. I don't know if it's the same, but it looks like it's pretty similar. So the ideas to support that (non-Unix) semantics are the same as Nick's.
> 
> 1. Implement a new Resolver behavior for Darwin/Windows. The behavior would be like this: Make Resolver to add all symbols from archive files to the symbol table as it processes new files, constructing a gigantic symbol table that contains all the symbols that is already resolved or *could* be resolved in a file that Resolver has seen. For a new object file, Resolver looks up the symbol table for each undefined symbol in an object file, and if it can be resolved in an (unparsed) archive file, parse the archive file, and add the symbols from the file to the symbol table.
> 
> 2. Create a group for all library files and add it at the end of the input graph, as Nick suggested in that thread.
> 
> So, (2) would be a low-impact change because it won't need any change to the core linker. However it would be slow because it needs to iterate over and over on the same library files until all undefined symbols are resolved. (1) would be faster because the iteration would be replaced by a single hash table lookup, but it'd be a high-impact change.

How ld64 deals with this is that each library (dylib or archive) has its table of available symbols.  These tables are managed the library File object.   The Resolver first gets all .o files.  Then for each remaining undefined symbol, it asks each library (in command line order) if they can provide a definition for it.  This test is cheap because it is just a hash probe.  If a dylib can provide it, the dylib instantiates a SharedLibraryAtom object which is added to the Resolver.  If an archive can provide it, the member is instantiated into a set of atoms (File) which are added to the Resolver.

The symbol lookup is library specific.  For Shared Libraries the File object looks at the same mach-o symbol information (it is a trie) that the runtime loader would  use to find a symbol.  For archives, the File object looks at the table of contents.

Thus, there is no need for a huge combined hash table, but you still get reasonably fast lookups.

-Nick


> 
> 
> 
> On Fri, Nov 22, 2013 at 2:38 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:
> On 11/22/2013 4:19 PM, Rui Ueyama wrote:
> On Fri, Nov 22, 2013 at 2:14 PM, Shankar Easwaran
> <shankare at codeaurora.org>wrote:
> 
> If its doing that, it might be following the Darwin model. The Darwin
> model picks up all the object files and puts all the libraries that it
> wants to link inside a Group(Snipped from a discussion earlier with Nick).
> 
> Which thread?
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-September/065365.html
> 
> Thanks
> 
> Shankar Easwaran
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131122/67db307c/attachment.html>