> > Moreover we do have all infrastructure ready to implement 3). Our tree > > merging > > and symbol table handling is fuly incremental and I think made a patch to > > implement it today. The scheme is easy: > > What happens when .S (assembler) files are part of the incremential object? > The kernel does that. Your patch would do the final generation in this case, > right?
Yes, it will spit out warning (which can be silenced -Wl,-rnolto is used) and turn the whole object into non-LTO one. > > In theory we could change the build system to avoid that case though, but > it would need some changes. > > It would be better if that could be handled somehow. How does this work with your patchset? Ideally we should have way to claim only portions of object files, but we don't have that. If we claim the file, the symbols in real symbol table are not visible. I suppose we could play a games here with slim LTO: claim the file, see if there are any symbols defined in the non-LTO symbol table and if so, interpret read the symbol table and tell linker about the symbols and at the very end include the offending object file in the list of objects returned back to linker. The linker then should take the symbols it wants. There would be some fun involved, because the resolution info we get will consider the symbols defined in that object file to be IR which would need to be compensated for. Honza
