On Tue, Jan 18, 2011 at 4:27 PM, 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.
I think -pass-through is a hack and linker should simply ignore it.
>
> 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.
>
It sounds a real progress.
BTW, can you check if the modified gold works on
PR ld/12248
PR ld/12277
PR ld/12291
PR ld/12323
PR ld/12365
PR ld/12369
Thanks.
--
H.J.
