On Jun 4, 2008, at 1:45 PM, Ian Lance Taylor wrote:
The result is that the plugin is required to do
symbol resolution itself. This 1) loses one of the benefits of
having
the linker around; 2) will yield incorrect results when some non-
LTO
object is linked in between LTO objects but redefines some earlier
weak symbol.
In the LLVM LTO model, the plugin only needs to know about its .o
files, and the linker uses this information to reason about symbol
merging etc. The Mac OS X linker can even do dead code stripping
across Macho .o files and LLVM .bc files.
To be clear, when I said object file here, I meant any input file.
You may have understood that.
In ELF you have to think about symbol overriding. Let's say you
link
a.o b.o c.o. a.o has a reference to symbol S. b.o has a strong
definition. c.o has a weak definition. a.o and c.o have LTO
information, b.o does not. ELF requires that a.o call the symbol
from
b.o, not the symbol from c.o. I don't see how to make that work
with
the LLVM interface.
This does work. There are two parts to it. First the linker's
master
symbol
table sees the strong definition of S in b.o and the weak in c.o and
decides to use the strong one from b.o. Second (because of that) the
linker
calls lto_codegen_add_must_preserve_symbol("S"). The LTO engine then
sees it has a weak global function S and it cannot inline those. Put
together
the LTO engine does generate a copy of S, but the linker throws it
away
and uses the one from b.o.
OK, for that case. But are you asserting that this works in all
cases? Should I come up with other examples of mixing LTO objects
with non-LTO objects using different types of symbols?
I don't claim our current implementation is bug free, but the lto
interface
matches the Apple linker internal model, so we don't expect and have
not encountered any problems mixing mach-o and llvm bitcode files.
-Nick
