Re: Update LTO plugin interface

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Thu, Dec 2, 2010 at 5:39 PM, Ian Lance Taylor <iant@google.com> wrote:
> 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.
>

All those complexities make 2 stage linking more attractive.  I
think I can implement it in GNU linker with the current plugin API.

Linker just needs to remember the command line options, including

--start-group/--end-group
-as-needed/--no-as-needed
--copy-dt-needed-entries/--no-copy-dt-needed-entries

in stage 1.

In stage 2, it will place LTO trans files before the first IR file
claimed by plugin and process the command line options.

--whole-archive may need some special handling.  Archives
after --whole-archive will be ignored in stage 2.


-- 
H.J.