[Bug binutils/23460] regression: ar can not create archive containing many (>1024) lto object files

[zenith432 at users dot sourceforge.net]

https://sourceware.org/bugzilla/show_bug.cgi?id=23460

--- Comment #23 from zenith432 at users dot sourceforge.net ---
(In reply to Nick Clifton from comment #22)
> I am confused by this part of the patch:
> 
>   for (plugin_list_iter = plugin_list;
>        plugin_list_iter != NULL;
>        plugin_list_iter = plugin_list_iter->next)
>     {
>       if (plugin_handle == plugin_list_iter->handle)
>         {
>           dlclose (plugin_handle);
>           if (!plugin_list_iter->claim_file)
>             return 0;
>           register_claim_file (plugin_list_iter->claim_file);
>           goto have_claim_file;
>         }
>     }
> 
> If I am reading this correctly, this says that if we are attempting to 
> load a plugin that was previously loaded, then we call dlclose() on it,
> and then, if the plugin has a file claim function, we register this 
> function as the global file claimant, despite the plugin having been
> closed...
> Is that right ?

Not quite.  The first time a plugin is loaded, it's not in the linked list, so
the for loop you quoted gets skipped.  The plugin's dlopen() refcount is set to
1, the code later on creates a linked-list item for it and initializes it with
the handle, it's claim_file and links the item.
The 2nd or subsequent times a plugin is loaded, the dlopen() bumps its refcount
to 2, the plugin's handle is found in the linked list, calling dlclose()
reduces the refcount back to 1 (to keep it from growing unbounded).  The plugin
is still loaded (with refcount 1), and the cached claim_file pointer which was
found during the initial load is installed.

> Also  - it seems to me that if we have a list of loaded plugins, then
> we no longer need the claim_file global variable, and the try_claim() 
> function should walk the list of plugins, trying each in turn.

I agree, but I was trying to keep the logic localized to try_claim_plugin()
which is called with a specific plugin name and input file.  Your suggestion
requires refactoring the code at a higher level.  It is entered via
bfd_plugin_object_p() which is referenced from plugin_vec - and is called for a
specific input file.  Then it goes to load_plugin() which iterates over plugins
by name for a given input file.  load_plugin() in turn calls try_claim_plugin()
with a specific plugin name and input file.

-- 
You are receiving this mail because:
You are on the CC list for the bug.