> 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 else that may generate ELF objects to generate this magic object. But why not just ELF directly? that is what it is after all. 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. -Andi