Re: "ld -r" on mixed IR/non-IR objects (

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Dec 10, 2010 at 4:39 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Dec 10, 2010 at 7:13 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Thu, Dec 9, 2010 at 8:55 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Thu, Dec 9, 2010 at 6:29 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Wed, Dec 8, 2010 at 9:36 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>> On Wed, Dec 8, 2010 at 5:54 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>> On Wed, Dec 8, 2010 at 1:19 AM, Andi Kleen <andi@firstfloor.org> wrote:
>>>>>>>> On 12/07/2010 04:20 PM, Andi Kleen wrote:
>>>>>>>>>
>>>>>>>>> The only problem left is mixing of lto and non lto objects. this right
>>>>>>>>> now is not handled. IMHO still the best way to handle it is to use
>>>>>>>>> slim lto and then simply separate link the "left overs" after deleting
>>>>>>>>> the LTO objects. This can be actually done with objcopy (with some
>>>>>>>>> limitations), doesn't even need linker support.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Quite possibly a better way to deal with that is to provide a mechanism
>>>>>>>> for encapsulating arbitrary binary code objects inside the LTO IR.
>>>>>>>
>>>>>>> Then you would need to teach your assembler and everything
>>>>>>
>>>>>> The magic section is generated by linker directly. No changes to
>>>>>> assembler is required.
>>>>>>
>>>>>>> else that may generate ELF objects to generate this magic object. But why
>>>>>>> not just ELF directly? that is what it is after all.
>>>>>>
>>>>>> My proposal isn't specific to ELF.
>>>>>>
>>>>>>>
>>>>>>> To be honest I don't really see the point of all this complexity you
>>>>>>> guys are proposing just to save fat LTO. Fat LTO is always a bad idea
>>>>>>> because it's slow and ?does lots of redundant work. If LTO is to become
>>>>>>> a more wide spread mode it has to go simply because of the poor
>>>>>>> performance.
>>>>>>>
>>>>>>> With slim LTO passthrough is ?very straight-forward: simple pass
>>>>>>> through every section that is not LTO and generate code for the LTO
>>>>>>> sections. No new magic sections needed at all.
>>>>>>>
>>>>>>
>>>>>> My proposal works on both fat and slim LTO objects. ?The idea is
>>>>>> you can use "ld -r" on any combination of inputs and its output
>>>>>> still works as before "ld -r".
>>>>>>
>>>>>
>>>>> Here is the revised proposal.
>>>>>
>>>>
>>>> The initial implementation of my proposal is available on hjl/lto-mixed
>>>> branch at
>>>>
>>>> http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary
>>>>
>>>> Simple case works. ?More cleanups are needed. ?Feedbacks
>>>> are welcome.
>>>>
>>>
>>> I checked in patches to remove temporary files.
>>>
>>>
>>
>> More fixes are checked in. ?I will try Linux kernel next.
>>
>
> I checked in new fixes. "ld -r" works on Linux kernel build.
> But the final kernel link failed due to unrelated errors.
>

LTO work in BFD linker is done. I will submit a patch in the next
few days, which enables transparent LTO support in BFD linker.
No GCC changes are required.

-- 
H.J.