> Well, we'd then need to re-architect the symbol merging and > LTO unit read-in to properly honor linking semantics (drop > a LTO unit from an archive if it doesn't resolve any unresolved > symbols). I don't know how easy that will be, but it shouldn't > be impossible at least.
We also should keep in mind that we really ought to be able to produce LTO .o files without actual assembly in, so either we should not tie this too much with linking process anyway or we need to output fake symbols into the LTO .o file when assembly is not done. (I guess one can just output empty variables and functions, but then .o will link without LTO and lead to wrong code). This is IMO quite important feature, we don't want to double compile times forever. Honza > > > I'm sketching a plan where collect2 invokes 'ld' as if to do an ordinary > > non-LTO link, but passes it a flag like "--lto-assist" which causes it to > > output a list of just the archive members that it actually needs to complete > > the link, in response file "filenam...@offset" format. ISTM that this is > > the > > simplest method to avoid recompiling entire archives (sort of building a > > linker into the compiler!), and I guess I should also make it check for an > > LTO > > marker (whether symbol or section) and only output those members that > > actually > > contain any LTO data. > > Yes - that would be basically a linker plugin without plugin support. > And I'd go even further and have LD provide a complete symbol > resolution set like we get from the gold linker-plugin. > > That wouldn't help for old or non-gnu LDs of course. > > > Making lto1 understand archives seems logical at first, but I don't think > > it's much use without knowing which archive members we want in advance, and > > in > > that case the existing code that reads a single archive member by pretending > > it's an ordinary object file with a constant offset from the start of file > > marker already does all we need, or so it seems to me. > > I think we should try without lto1 understanding archives first > (or we are basically re-implementing a linker in lto1). > > Richard. > > > cheers, > > DaveK > > > >
