[patch] First step to fix pr11866 during LTO

[Nick Kledzik]

On Sep 5, 2013, at 2:28 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

>>> I understand what you are saying from llvm’s point of view, but to my original question:
>>> When would the linker call this new lto_codegen_add_symtab_symbol() function?
>> 
>> 
>> Does it call it on every weak symbol which it did not call lto_codegen_add_must_preserve_symbol() on?  If so, then what is the point.  The LTO interface should be able to infer that.
> 
> No. It calls it when the only reason it was going to call
> lto_codegen_add_must_preserve_symbol instead is if it wants it for the
> symbol table.
Why would the linker want it for the symbol table?  

The ld64 model is that LTO does whatever optimizations it can, with the restriction that some symbols must be preserved because they are referenced by native code or some linker command line option.   The LTO engine then hands the linker back a generated mach-o file.  The linker then adds whatever symbols are in that mach-o file to the final symbol table.  

> In the previous example, LLVM alone cannot tell the difference from F
> and G. It needs the linker to call
> lto_codegen_add_must_preserve_symbol on the one that is used from a .o
> (F) and  lto_codegen_add_symtab_symbol on the one that it wants just
> to put in a symbol table (G).

You said earlier calling lto_codegen_add_symtab_symbol() enables LTO to do more optimizations.  What would break if it was called on all symbols?

I see how this wires up to the gold plugin.  What I am trying to figure out is:
* Does ld64 need to call this new function, is so when would it call it?
* If ld64 does not call the new function, is it missing out on optimizations?

-Nick