[lld] r195289 - [PECOFF] Do not check if library is already added.
mikael at lyngvig.org
Tue Nov 26 06:30:03 PST 2013
Sorry for the late answer, you mail accidentally made it into the thrash
The linker would issue an error or a warning but continue the link as if
nothing had happened. This is important if you want to override a set of
library symbols like malloc and free without having access to the source
2013/11/22 Rui Ueyama <ruiu at google.com>
> Thank you Mikael for the very valuable comment. I did not understand the
> exact semantics of Windows-style link resolve order. We should definitely
> consider to use that method in the LLD, although I have no concrete idea to
> do that at this moment. Currently the LLD supports only Unix-style symbol
> resolve order.
> One question is that you said that you can override a library symbol by
> giving a file containing the same symbol before the library. Doesn't it
> cause the linker to fail with duplicate symbol error?
> On Wed, Nov 20, 2013 at 5:33 PM, Mikael Lyngvig <mikael at lyngvig.org>wrote:
>> As a former DOS/NT linker engineer (SSI, XLINK386, an absolute embedded
>> linker - probably the world's most advanced linker ever), I'd like to add
>> that Windows linkers don't search in the Unix-style one way only. On
>> Windows, you can do things like foo.obj kernel32.lib oldnames.lib without
>> running into problems. On Windows, the linkers typically make a gigantic
>> symbol table of all the symbols defined in the input files and then resolve
>> that way. The only time the link order matters is if there are duplicate
>> symbols, in which case the first input file that provides the symbol is
>> picked so that the user can predict what happens if he or she overrides a
>> library symbol.
>> I think you should consider to use that method in lld as the Unix method
>> is less than optimal: It is not a rare sight that a Unix link fails only
>> because of wrong library order. Then you have to sit and juggle the
>> linker's input files for a while, until the beast caves in and does what
>> you expect it to do: Link with the least amount of trouble on your parth.
>> -- Mikael
>> 2013/11/21 Rui Ueyama <ruiu at google.com>
>>> For some reason, the reason of this change was omitted from the commit
>>> message. Here's the description I meant to include in the commit log.
>>> Pasting it for the record.
>>> Currently the LLD checks if a library specified with /defaultlib is
>>> added to the input graph and do not add if it's already there. It causes
>>> some undefined symbols remain unresolved.
>>> For example, oldnames.lib depends on kernel32.lib. What happens if
>>> /defaultlib:kernel32.lib is given from the command line? The LLD reads
>>> section of oldnames.lib, finding that it contains
>>> However, the LLD won't add the kernel32.lib to the input file list
>>> because it's
>>> already added.
>>> The resolve order in the above case is kernel32.lib and oldnames.lib. So,
>>> undefined symbols in oldnames.lib, which need to be resolved by
>>> remains undefined. It's a wrong behavior.
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits