[whopr] Design/implementation alternatives for the driver and WPA

[Nick Kledzik]

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