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

[Rui Ueyama]

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.



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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131122/8685b8d7/attachment.html>