https://sourceware.org/bugzilla/show_bug.cgi?id=32153
--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> --- This is very similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116361 LLVM could implement LDPT_REGISTER_CLAIM_FILE_HOOK_V2: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617277.html /* Callback used by a linker to check if the plugin can claim FILE. Writes the result in CAN_BE_CLAIMED. If KNOWN_USED != 0, the object is known by the linker to be included in link output, or an older API version is in use that does not provide that information. Otherwise, the linker is only determining whether this is a plugin object and only the symbol table is needed by the linker. In this case, the object should not be included in link output and this function will be called by the linker again with KNOWN_USED != 0 after the linker decides the object should be included in link output. */ This change: diff --git a/bfd/plugin.c b/bfd/plugin.c index f6c6fdbee69..b481c35115f 100644 --- a/bfd/plugin.c +++ b/bfd/plugin.c @@ -597,7 +597,7 @@ static bfd_cleanup bfd_plugin_object_p (bfd *abfd) { if (ld_plugin_object_p) - return ld_plugin_object_p (abfd, false); + return ld_plugin_object_p (abfd, true); if (abfd->plugin_format == bfd_plugin_unknown && !load_plugin (abfd)) return NULL; works for this test. I don't think that it will work for all cases. -- You are receiving this mail because: You are on the CC list for the bug.
