<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Nov 22, 2013, at 3:40 PM, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">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.<div><br></div><div>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.</div>
<div><br></div><div>2. Create a group for all library files and add it at the end of the input graph, as Nick suggested in that thread.</div><div><br></div><div>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.</div></div></blockquote><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thus, there is no need for a huge combined hash table, but you still get reasonably fast lookups.</div><div><br></div><div>-Nick</div><div><br></div><div><br></div><div><blockquote type="cite"><div dir="ltr">
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 22, 2013 at 2:38 PM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 11/22/2013 4:19 PM, Rui Ueyama wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Nov 22, 2013 at 2:14 PM, Shankar Easwaran<br>
<<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>><u></u>wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If its doing that, it might be following the Darwin model. The Darwin<br>
model picks up all the object files and puts all the libraries that it<br>
wants to link inside a Group(Snipped from a discussion earlier with Nick).<br>
<br>
</blockquote>
Which thread?<br>
</blockquote>
</div><a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-September/065365.html" target="_blank">http://lists.cs.uiuc.edu/<u></u>pipermail/llvmdev/2013-<u></u>September/065365.html</a><br>
<br>
Thanks<span class="HOEnZb"><font color="#888888"><br>
<br>
Shankar Easwaran<br>
</font></span></blockquote></div><br></div>
_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits<br></blockquote></div><br></body></html>