On Tue, 8 May 2018, Jan Hubicka wrote: > > On Tue, May 8, 2018 at 8:14 AM, Jan Hubicka <hubi...@ucw.cz> wrote: > > > Hi, > > > with lto, incremental linking can be meaninfuly done in three ways: > > > 1) read LTO file and produce non-LTO .o file > > > this is current behaviour of gcc -r or ld -r with plugin > > > 2) read LTO files and merge section for later LTO > > > this is current behaviour of ld -r w/o plugin > > > 3) read LTO files into the compiler, link them and produce > > > incrementaly linked LTO object. > > > > > > 3 makes most sense and I am maing it new default for gcc -r. For testing > > > purposes > > > and perhaps in order to have tool to turn LTO object into real object, we > > > want > > > to have 1) available as well. GCC currently have -flinker-output option > > > that > > > decides between modes that is decided by linker plugin and can be > > > overwritten > > > by user (I have forgot to document this). > > > > > > I am targeting for -flinker-output=rel to be incremental linking into LTO > > > and adding -flinker-output=nolto-rel for 1). > > > > > > The main limitation of 2 and 3 is that you can not link LTO and non-LTO > > > object files theger. For 2 HJ's binutils patchset has support and I think > > > it can be extended to handle 3 as well. But with default binutils we want > > > to warn users. This patch implements the warning (and prevents linker > > > plugin > > > to add redundat linker-ouptut options. > > > > > > My users/hjl/lto-mixed/master branch is quite flexible. I can extend > > it if needed. > > I think once the main patchset settles down we could add a way to communicate > to lto-plugin if combined lto+non-lto .o files are supported by linker and > sillence > the warning.
How does the patchset deal with partially linking fat objects? How do HJs binutils deal with them when you consider a fat object partially linked with a non-LTO object? Richard. -- Richard Biener <rguent...@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)