On Fri, Dec 10, 2010 at 4:39 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Fri, Dec 10, 2010 at 7:13 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >> On Thu, Dec 9, 2010 at 8:55 PM, H.J. Lu <hjl.to...@gmail.com> wrote: >>> On Thu, Dec 9, 2010 at 6:29 PM, H.J. Lu <hjl.to...@gmail.com> wrote: >>>> On Wed, Dec 8, 2010 at 9:36 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >>>>> On Wed, Dec 8, 2010 at 5:54 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >>>>>> On Wed, Dec 8, 2010 at 1:19 AM, Andi Kleen <a...@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.
