[5/6][PATCH] Perform second link stage and ignore now-obsolete linker -pass-through= option.

[Dave Korn <dave.korn.cygwin@gmail.com>]

    Hi list,

  This is the second main functional change, and it's really the only way to
resolve the problems caused by discrepancies between the initial set of
symbols returned by the plugin based on the LTO symtabs in the IR files, and
the actual set of symbols used and defined by the eventual object file(s)
added to the link after LTRANS.  It's largely the same approach as HJ's
2-stage link, except that it closes and reopens the existing input BFDs in
place, rather than adding a second set of input statements.  This results in
some different behaviour between HJ's linker and this patched version.


ld/ChangeLog:

2011-02-20  Dave Korn  <...

	PR ld/12365
	* ldcref.c (cref_hash_table_free): New function.
	* ld.h (cref_hash_table_free): Add prototype.
	* ldlang.c (lang_gc_sections): Dont de-exclude claimed file sections.
	(set_exclude): New function.
	(reopen_inputs): Likewise.  Walk list of input objects, excluding
	claimed (IR-only) files and archive members, then re-walk list, closing
	and re-opening and re-adding the symbols from objects and libs.
	(lang_process): After opening plugin-supplied objects and scanning
	their library dependencies, tear down existing link, cref and
	already-linked-section hashes, erase link_info input bfds list, finally
	call reopen_inputs.
	* plugin.c (plugin_opt_plugin_arg): Discard any instances of the
	now-obsolete "-pass-through=" option if found.

  I know Ian would rather avoid this approach, but I don't think that there's
any other way to do LTO in LD without either rearchitecting BFD quite a bit.
We can't do symbol resolution without adding symbols from the LTO symtabs into
the linker hash table, but then after LTRANS we may have a different final set
of symbols present.  There's no way to excise individual symbols from the
linker hash table in BFD, so you have to achieve the same effect by tearing
down the symbol table and rebuilding it without adding the unwanted symbols at
all second time round.  That means you have to close and reopen all the BFDs,
because BFD backends cache pointers to hash table entries in the bfd's private
data, which are now stale once you've built a new symbol table.  I can't see
any way around having to re-do at least this amount of work, but without it
we'll get bogus symbols in our final outputs, which is a real correctness issue.

    cheers,
      DaveK