Update LTO plugin interface

[Ian Lance Taylor]

Cary Coutant <ccoutant@google.com> writes:

>> 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.
>
> I wouldn't expect the compiler to introduce a call to anything in libm
> when -lm isn't already specified on the command line (that would break
> even without LTO).

Right--that would break without LTO, but it doesn't follow that we
should make it work with LTO.

> With what I'm suggesting, we'll only resolve libcalls to libraries
> that were originally specified on the command line.

OK.  Another concern I have with this is that there is no canonical
location across all systems for some of these functions.  In general -lc
and -lm will suffice, but on some specific systems they may not.  And
there are functions which are in libc on some systems and in libm on
others, such as frexp.  So if we have a mapping from function to
library, I'm afraid we may get caught up in system dependencies which
are really kind of irrelevant.  What really matters, I think, is not the
specific library per function; it's the set of libraries we need to
rescan.


> Another way to do this would be to put a marker in the command line
> that identifies where those libraries begin, and the linker could just
> go back and rescan those libraries if needed, before the final layout
> of the endcaps.

I like that idea in general, but the difficulty is knowing where to put
the marker.  E.g., the user is going to specify -lm, and we are going to
need to rescan it.  If the user writes -lm -lmylib1 -lmylib2 we want to
rescan -lm but we don't really need to rescan mylib1 and mylib2.

Ian