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.
