This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Update LTO plugin interface


"H.J. Lu" <hjl.tools@gmail.com> writes:

> On Thu, Dec 2, 2010 at 11:37 AM, Ian Lance Taylor <iant@google.com> wrote:
>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>
>>> g++ adds -lm since libstdc++ uses libm. ÂIf we do it in gcc, we may
>>> add run-time dependency on libm.so to all C programs even if they
>>> don't use libm at all.
>>
>> No. ÂAll the gcc driver has to do is: *if* -lm is used on the link line,
>> also add it after the use of --plugin-callback.
>
> How many libraries specified at command line do we have to check?

We only have to check the ones for which LTO can potentially generate a
reference which did not exist in the original object file.  Or, more
precisely, for which LTO can generate a reference which the plugin did
not report when the original object file was seen.

As far as I can tell at this point, the complete set of libraries we
need to check is: -lc -lm -lgcc -lgcc_s.

We could remove -lm from that list if we arranged for the plugin to
report a potential reference to sin even if the object file does not
list it for whatever reason.  I saw your earlier test case but I don't
actually know why the reference to sin in the source code disappeared
from the object file and was reinserted by LTO.


> How do we handle -Wl, -Wl,-Bstatic/-Wl,-Bdynamic,-Wl,--start-group, ....
> and other linker switches?

A fair point.  Ideally we would want to recreate the state of those
options for all libraries explicitly mentioned by the user.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]