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


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.


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