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


-- 
H.J.


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