https://sourceware.org/bugzilla/show_bug.cgi?id=23460
--- Comment #16 from Evangelos Foutras <evangelos at foutrelis dot com> ---
(In reply to zenith432 from comment #15)
> ===== begin patch
> diff --git a/bfd/plugin.c b/bfd/plugin.c
> index d9b9e2f1..3b738c38 100644
> --- a/bfd/plugin.c
> +++ b/bfd/plugin.c
> @@ -274,7 +274,7 @@ have_claim_file:
> goto err;
>
> if (!try_claim (abfd))
> - goto err;
> + return 0;
>
> abfd->plugin_format = bfd_plugin_yes;
>
> ===== end patch
The above didn't allow a ThinLTO Chromium build to finish; there were missing
symbols during the final linking of the main binary.
Chromium built successfully with the following change (and unpatched LLVM):
==============================
diff --git a/bfd/plugin.c b/bfd/plugin.c
index d9b9e2f174..e12f37d36a 100644
--- a/bfd/plugin.c
+++ b/bfd/plugin.c
@@ -274,7 +274,7 @@ have_claim_file:
goto err;
if (!try_claim (abfd))
- goto err;
+ goto err_no_dlclose;
abfd->plugin_format = bfd_plugin_yes;
@@ -283,6 +283,7 @@ have_claim_file:
err:
if (plugin_handle)
dlclose (plugin_handle);
+ err_no_dlclose:
register_claim_file (NULL);
return 0;
}
==============================
The proposed approach seems to skip dlclose for most (all?) plugins. To my
untrained eye, it looks preferable to just do away with dlclose() altogether
instead of selectively skipping it.
The workaround on the LLVM side that builds LLVMgold.so with -Wl,-z,nodelete
has been tentatively merged. [1] Assuming it doesn't cause any regressions, the
use of dlclose() shouldn't be an issue anymore.
Finally, I will say that I don't understand the need to dlclose() plugins if
they don't claim a specific file. Doesn't this create unnecessary overhead of
opening and closing plugins for each member added to an archive (in the case of
ar)? Since previous binutils versions worked fine, I would think that the
problem was with file handles to object files being left open, and not plugins
that remained loaded.
[1] https://reviews.llvm.org/D50416
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
