Bug 16544 - Gold crashes with plugin
Summary: Gold crashes with plugin
Status: ASSIGNED
Alias: None
Product: binutils
Classification: Unclassified
Component: gold (show other bugs)
Version: 2.24
: P2 normal
Target Milestone: ---
Assignee: Cary Coutant
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-08 14:56 IST by Razvan Ghitulete
Modified: 2014-02-11 19:22 IST (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
input_file (16 bytes, application/x-archive)
2014-02-08 14:56 IST, Razvan Ghitulete
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Razvan Ghitulete 2014-02-08 14:56:18 IST
Created attachment 7398 [details]
input_file

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-2.24.51.0.1/gold/parameters.h:105

Attached input file.
Comment 1 Razvan Ghitulete 2014-02-08 14:59:49 IST
When enabling the plugin gold/workqueue.cc:319 seems to run gold/plugin.cc:1407 as well. This, in turn, triggers the assertion.
Comment 2 Cary Coutant 2014-02-11 19:22:36 IST
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.