ld: Restore file offset after a plugin fails to claim a file

When using the plugin interface to claim an input file the claim method
from (possible) many plugins can be called on an input file.  If these
claim methods read content from the input file then the file offset
stored in the underlying file descriptor will change.

As we share a file descriptor between the plugin interface (created with
dup in ld/plugin.c:plugin_object_p) and the input bfd object, then any
changes to the file offset in the file descriptor will effect the bfd
object.  Also, as the changes to the file offset did not originate from
calls through the bfd interface, but instead came from the plugin
directly, then the bfd will not be aware that the file offset has
changed.  This is a problem as the bfd library caches the file offset.
If the plugin decides not to claim an input file then, currently, we
leave the bfd in a state where the actual file offset is out of sync
with the cached file offset.

This problem came to light after a recent commit
7d0b9ebc1e0079271a7c7737b53bc026525eab64 (Don't include libbfd.h outside
of bfd, part 6) however, I don't believe that commit actual introduces
the bug, it just exposed the existing issue.

This commit solves the problem by backing up and restoring the file
offset for the file descriptor of the input file.  The restore is only
done if the plugin does not claim the input file, as it is in this case
that the bfd library might be used again to try and identify the
unclaimed file.

ld/ChangeLog:

	* plugin.c (plugin_call_claim_file): Restore the file offset after
	an unsuccessful attempt to claim a file.
	* testplug.c (bytes_to_read_before_claim): New global.
	(record_read_length): New function, sets new global
	bytes_to_read_before_claim.
	(parse_option): Handle 'read:<NUMBER>' option.
	(onclaim_file): Read file content before checking for claim.
	* testsuite/ld-plugin/plugin-30.d: New file.
	* testsuite/ld-plugin/plugin.exp: Add new test.

0 files changed, 0 insertions, 0 deletions