[Bug lto/46291] [4.6 Regression] Failed to bootstrap-lto

["davek at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46291

Dave Korn <davek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2010.11.03 20:49:18
         AssignedTo|unassigned at gcc dot       |davek at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #2 from Dave Korn <davek at gcc dot gnu.org> 2010-11-03 20:49:18 UTC ---
I have found the problem.  There is an ambiguity in the plugin interface spec.

http://gcc.gnu.org/wiki/whopr/driver says

" Input Files
  [ ... ]
  struct ld_plugin_input_file
  {
    const char *name;
    int fd;
  [ ... ]
  };
  [ ... ]
fd: An open file descriptor for the input file. The current position in the
file is undefined (i.e., the plug-in must call lseek before reading). If the
plug-in 
                                                                 ^^^^^^^^^^^^^^
claims the file, it will then own the file descriptor and has the
responsibility 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
for closing it. If the plug-in does not claim the file, it must leave it open,
but
^^^^^^^^^^^^^^^
it is not required to maintain the current position in the file. "

However it also says:

" Plugin Interfaces
  [ ... ]
4. 
  [ ... ]
Whether the file is claimed or not, the linker maintains responsibility for
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
opening and closing the file as necessary."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Oops.  Guess which way LD does it?  Guess which way GOLD does it?

Ian?  Which way should this really be?

While we decide, I have a patch that will fix lto-bootstrap by detecting which
linker is calling onload and deciding whether or not to close the fd on that
basis.