See also https://gcc.gnu.org/PR109128 (+ description in the patch log)

The linker plugin API was designed to handle LTO - such that the compiler (i.e. GCC's lto-plugin)
can claim an input file if it finds LTO code. In that case, the symbols inside that file are ignored
by 'ld'.

However, GCC also uses the LTO for offloading: code designated for running on a non-host device
(GPUs) is saved in a special section in LTO format. This code then ends up being compiled for
offloading but otherwise not the file is not claimed, keeping the symbols for 'ld' to process,
unless that file is also uses real, host-side LTO.

This mostly works okay, but a corner case exists (see PR for an example) where 'ld' calls the
GCC's lto-plugin but does not actually use the symbols of that file. That's fine, in principle,
but if that file contains offloading code, there is a problem: To match host and device functions,
a table is created on both sides, but that table obviously must match. However, when lto-plugin's
offload code processes those while ld does not link them, it fails.

It turned out (kudos to Joseph for debugging + writing the patches) that in that case ld.bfd does
not actually regards that file as being used but just offers it to llto-plugin in case it needs
symbols from it.

To get this working, the current API is insufficient.

Possible solutions:
* Tell lto-plugin whether 'ld' actually needs symbols from a file or it just offers the file
   in case that lto-plugin wants to claim that file
   => That's implemented in the attached patch.
* Make it possible to "claim" a file without discarding the ld-visible symbols
* Asking the linker later whether the file/some symbols are actually used.
* something else ...


What this patch does:
* It adds a new API callback (LDPT_REGISTER_CLAIM_FILE_HOOK_V2) that takes an additional
   boolean argument which states whether ld.bdf intens to use that file/symbols from that
   file or whether it just asks the plugin in case it wants to claim it.
* On the ld.bfd side, it wires this up.
* On the GCC lto-plugin side, it uses that API is available, otherwise it uses the existing API.

The way the linker plugin handling is written, it works fine at runtime if only one side
supports the new hook. (Except, of course, that for fixing the issue both need to support it.)

Regarding those patches: Are they ok for mainline? Any comment, better approach, suggestion?

Tobias

PS: Attached is the Binutils' ld side of the patch and the GCC lto-plugin side of the patch set.
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955