This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Update LTO plugin interface
On Thu, Dec 2, 2010 at 10:37 AM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>> On Thu, Dec 2, 2010 at 9:41 AM, Ian Lance Taylor <iant@google.com> wrote:
>>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>>
>>>> How do you deal with -lm:
>>>
>>> I believe we have agreed that LTO can only introduce new symbol
>>> references that are satisfied by -lc and -lgcc. ?Under those conditions,
>>
>> Have you looked my testcase? The assumption of "LTO can only
>> introduce new symbol references that are satisfied by -lc and -lgcc."
>> is wrong. ?My testcase shows LTO may introduce new symbol references
>> to libm.
>
> You're right, I didn't fully grasp that the reference to sin in the
> source code was somehow being removed and then re-added.
>
> However, I really don't see why this is a serious flaw in my proposal.
> You have shown a case in which LTO can introduce a new symbol reference
> to -lm. ?So we just treat -lm as we do -lc and -lgcc. ?This is similar
> to how the g++ driver already treats -lm. ?It's a detail, not a major
> problem.
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.
> A major problem would be if LTO could introduce a new symbol reference
> which required changing the way we search user defined archives.
>
Your proposal means we have to add lots of library references to
GCC driver. I am not sure if it is a good idea.
--
H.J.