Created attachment 7398 [details]
When running gold with a plugin for an ar file it crashes by hitting an assert. This does not occur when running without a plugin enabled (although the plugin does not handle ar files at all)
$ ld.gold -plugin /opt/llvm/lib/LLVMgold.so -o output ar_file
ld.gold: internal error in target, at binutils-184.108.40.206.1/gold/parameters.h:105
Attached input file.
When enabling the plugin gold/workqueue.cc:319 seems to run gold/plugin.cc:1407 as well. This, in turn, triggers the assertion.
The problem is that gold hasn't yet seen any real (i.e., non-plugin) .o files to establish what the target architecture is. Before plugins, this really was a "can't happen" path; hence the internal error. It shouldn't be diagnosed as an internal error in this case, but we really need to see a real .o before anything else. Normally, the compiler passes in various startup files.
There's no simple way of relaxing this requirement, short of changing the plugin API to allow the plugin to specify the target architecture if necessary.
I can fix it to print a real diagnostic, but I don't plan to support the case where all input files are claimed by the plugin.