[patch] First step to fix pr11866 during LTO

[Rafael Espíndola]

> 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.

It is the same model with gold, we are just passing a more information
(why the symbol is wanted). In the example

-------------------------------
void f();
struct foo {
  typedef void (foo::*mptr)();
  virtual mptr zed();
  void bar() {
  }
  __attribute__((noinline)) void baz() {
    f();
  }
  virtual void bah() {
  };
};
foo::mptr foo::zed() {
  baz();
  return &foo::bar;
}
-----------------------------

The linker by itself has no way of knowing that baz and bah can be
omitted from the dynamic library symbol table. It is llvm that can
figure out that their address are not needed and that they are
linkonce_odr *once the linker has told it that no other .o uses it by
calling  add_symtab_symbol instead of add_required*.


>> 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?

Calling it *instead of  lto_codegen_add_must_preserve* enables more
optimizations. Calling it on every symbol would for example prevent
internalizing a hidden symbol, which the linker knows is not used
anywhere (including symbol table).

> 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?

It doesn't need, no. The existing add_must_preserve is sufficient for
correctness.

> * If ld64 does not call the new function, is it missing out on optimizations?

Yes, it would get baz and zed in the symbol table of a .dylib when
llvm would otherwise be able to drop them.

Cheers,
Rafael