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

[Rui Ueyama]

Thanks. I don't know if it's exactly the same, but it looks like it's
pretty similar. So the ideas to support that (non-Unix) semantics are
basically the same as Nick's.

1. Implement a new Resolver behavior for Darwin/COFF. The behavior would be
like this: Make Resolver to add all symbols from library 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 library 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) library file, parse the
library 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 is replaced by a single
hash table lookup, but it'd be a high-impact change.

Currently, COFF port is similar to (2), but instead of creating a group, it
adds the same library to the input graph multiple times. That should be
even slower than (2), so it needs improving.

I'd think we ultimately want to go with (1), because it feels that it's the
native behavior for Darwin/COFF. (2) is a workaround to simulate that
within Unix's linker semantics.


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/e81a6da1/attachment.html>