Update LTO plugin interface

[Ian Lance Taylor]

Cary Coutant <ccoutant@google.com> writes:

>> For each libcall, we need to decorate
>>
>> 1. Which library it comes from. It is OS/target dependent.
>> 2. The dynamic and static library names.  In most cases,  they
>> are the same.  For glibc, they are different.
>
> Is there a relatively painless way to enumerate all the possible
> libcalls? We could add a new plugin api and have the LTO plugin
> register those symbols up front. The linker would make a note of where
> each symbol is defined, and then automatically go back and add any
> objects needed to resolve any references introduced by the
> optimization pass.

This isn't quite what should happen, though.  If the user does not
specify -lm on the link line, then we should not add -lm, even if LTO
somehow introduces a function that is defined in libm.  Automatically
adding -lm would introduce a surprising dynamic dependency in some
cases.  The user should be explicit about that.

That is, it really doesn't matter which library libcalls come from.  All
we need to know is which libraries might satisfy new libcalls.

This is what leads me in the direction of copying certain libraries
mentioned on the command line to follow the LTO objects, much as
-pass-through does.  I think we just need to make that a little bit more
automatic.

Ian