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: "ld -r" on mixed IR/non-IR objects (


On Mon, Dec 6, 2010 at 3:09 PM, Andi Kleen <andi@firstfloor.org> wrote:
>> On Mon, Dec 6, 2010 at 2:43 PM, Andi Kleen <andi@firstfloor.org> wrote:
>>>> Hi,
>>>>
>>>> "ld -r" doesn't work with mixed IR/non-IR objects:
>>>>
>>>> http://www.sourceware.org/bugzilla/show_bug.cgi?id=12291
>>>
>>> There are various bugs for it in gcc bugzilla too.
>>>
>>>> Some compilers support it. Should it be supported?
>>>
>>> Yes. I've been working on it (slim lto was the first part needed for it,
>>> without slim lto it's imho hopeless)
>>
>> Slim lto is a workaround, not a real solution.
>
> Actually I consider fat lto as a workaround for toolchain deficiencies.
> Generating everything twice and throwing one copy away is always
> inefficient. IMHO slim lto is the natural way to do LTO.

The idea is the same object file can be used with compilers
which don't support LTO.

> The only problem is that you need to fix every piece in the toolchain
> to not mess up LTO.
>
> That's why I did the gcc-ar,nm etc. wrappers. There were other problems
> too, like gcc's build system itself not handling LTO correctly (it normally
> only works because fat saves the day)
>
>> I think this support should
>> be
>> implemented in ld with help from GCC.
>
> Without slim lto you never know if a duplicate symbol is a mistake
> of the programmer or just the "fat lto" copy. Also ELF semantics
> like weak are hard if you have multiple copies.
>

It isn't easy, but doable.


-- 
H.J.


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