Update LTO plugin interface

H.J. Lu hjl.tools@gmail.com
Thu Dec 2 19:59:00 GMT 2010

On Thu, Dec 2, 2010 at 11:53 AM, Ian Lance Taylor <iant@google.com> wrote:
> "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.

It isn't a complete list. At least, we need -lgcov and may be others.

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

It can get quite complex. You start turning GCC driver into a linker :-).
What do we do when a new switch is added to linker?


More information about the Gcc mailing list