PATCH: 2 stage BFD linker for LTO plugin

[Ian Lance Taylor]

Alan Modra <amodra@gmail.com> writes:

> On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote:
>> Personally, I think 2 stage linking is one way to fix this issue.
>
> Ian has stated that he thinks this is a really bad idea.  I haven't
> approved the patch because I value Ian's opinion, and can see why he
> thinks it is the wrong way to go.  On the other hand, BFD is full of
> bad ideas..  I'm not strongly opposed to your patch myself.

Here is an alternative proposal, with a patch for gold.

We add a new plugin vector: LDPT_REGISTER_RESCAN_ARCHIVE_HOOK.  Like
LDPT_REGISTER_CLAIM_FILE_HOOK, this gives the plugin the address of a
function which can register a plugin function: rescan_archive.

typedef
enum ld_plugin_status
(*ld_plugin_rescan_archive_handler) (
  const struct ld_plugin_input_file *file, int *rescan);

If the plugin registers this hook, the linker will call the hook for
each archive that it sees.  If the hook sets the *rescan variable to a
non-zero value, then the linker will rescan the archive after calling
the all_symbols_read hook.  The archive will be rescanned using the same
position dependent options as when it was originally scanned.  In
particular, if the archive occurred within --start-group/--end-group,
the entire group will be rescanned.

The point of this patch is that the known problems with the LTO plugin
are when the plugin introduces a previously unknown symbol which must be
satisfied from some archive.  The new symbol is introduced when the
all_symbols_hook read hook calls add_input_file to add a new object file
to the link, and the new object file refers to the new symbol.  Since
the symbol was not previously seen, if the definition should come from
an archive, the archive will not have been searched.  Hence the test
case in GCC PR 42690 comment #32.

Fortunately, we know that gcc is not going to introduce arbitrary new
symbol references.  The current system hacks around the problem by using
a special -pass-through option which directs the plugin to add specific
archives to the link, namely -lc and -lgcc.  That works for most cases,
but not when gcc introduces a symbol which comes from -lm.  Still,
despite the -lm issue, we do not have to concern ourselves with
arbitrary archives, because gcc is not going to act arbitrarily.

Also we know that the problem can only occur with archives, not with
shared objects.

The rescan_archive proposal fixes the problems and obviates the need to
use -pass-through.  It avoids the unnecessary cost of a complete relink.

I've appended a patch for gold which implements this proposal.  I've
also appended a patch for lto-plugin.  This patched lto-plugin does not
use -pass-through when rescan_archive is available.  It rescans libc.a,
libgcc.a, and libm.a.  It handles the PR 42690 comment #32 test case
correctly.

Any thoughts on this approach?

Ian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.patch
Type: text/x-diff
Size: 12827 bytes
Desc: gold patch
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20101213/afdc573b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo1.patch
Type: text/x-diff
Size: 2199 bytes
Desc: lto-plugin patch
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20101213/afdc573b/attachment-0001.bin>