> On Wed, Jan 19, 2011 at 1:27 AM, Ian Lance Taylor <i...@google.com> wrote: > > After some discussion on IRC, here is another approach to resolving the > > issue with static linking and LTO. > > > > In this approach, the linker keeps track of all archives found after the > > first file claimed by the plugin. If the plugin adds any object files, > > and the object files refer to any symbols which are not yet defined, > > then the linker will scan all the saved archives, in order, for a > > definition of the symbol. If a definition is found, the linker will > > pull in the appropriate object from the archive. If that object, in > > turn, has any undefined symbols, the linker will pull in the appropriate > > object from that archive or any later ones, and so forth. The linker > > will honor --start-group/--end-group while rescanning. > > > > This should ensure that any previously unseen undefined symbols > > introduced by the compiler are handled correctly. I think it is > > appropriate to do this unconditionally when using plugins, as there is > > no other reasonable way to handle undefined symbols in a file added by a > > plugin. > > > > I've appended a patch to gold which implements this approach. The patch > > is reasonably efficient and introduces no unnecessary file I/O. With > > this patch to gold, and no change to gcc, the problematic -static test > > cases which I know about pass. Also all the current lto.exp tests pass. > > All those tests also pass if I edit the gcc LTO plugin to ignore the > > -pass-through option, as that option is not necessary when the linker > > implements this approach. > > > > As this patch does not require any changes to gcc, and fixes some cases > > which are clearly bugs, I plan to commit this patch to binutils mainline > > and to binutils 2.21 branch after a few days if I don't hear any > > comments. > > Nice. Can we on the GCC side somehow identify Gold versions > that support this and avoid -pass-through handling in that case? > I'm not sure if with your patch the add_input_library or > add_input_file plugin hooks are completely useless (and thus > gold could simply ignore those at all).
Nice indeed. I think we should version tag the plugin interface and handle this as version 1.1 or something. We also want to add the PREVAILING_IRONLY_EXT and other bits that will need some housekeeping of what plugin interface the linker provides. Honza