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

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

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.


-- 
H.J.

Attachment: mixed-IR.txt
Description: Text document