Bug 682852

Summary:	Feature Request: Enable gold plugin support
Product:	[Fedora] Fedora	Reporter:	Tilmann Scheller <tilmann.scheller>
Component:	binutils	Assignee:	Nick Clifton <nickc>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	15	CC:	fullung, jakub, liblit, nickc
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-05-27 12:25:08 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Tilmann Scheller 2011-03-07 19:15:08 UTC

Right now gold is built without plugin support.

If there is no particular reason for disabling it, it would be really cool if gold could be built with plugin support in the future.

It would make it a lot easier to use the LLVM gold plugin (http://llvm.org/docs/GoldPlugin.html) on Fedora, making LTO builds with LLVM/clang work almost out of the box.

Thanks!

Comment 1 Nick Clifton 2011-03-08 16:27:19 UTC

Try binutils-2.21.51.0.6-2.fc16, now with Gold plugins are enabled. :-)

Cheers
  Nick

Comment 2 Tilmann Scheller 2011-03-09 18:40:36 UTC

Thanks for the new build!

I'm going to install rawhide in a VM and will give it a try :)

Comment 3 Tilmann Scheller 2011-03-14 19:04:30 UTC

I gave the new build a try and I noticed two issues:

nm and ar always said "sorry - this program has been built without plugin support" when I tried to use them with the --plugin LLVMgold.so option. Can you enable plugin support for them as well?

ld.gold on the other hand worked fine when passed --plugin LLVMgold.so, successfully creating a native executable from several LLVM bitcode files :)

In order to build LLVMgold.so I had to obtain the plugin-api.h header from gold which defines the public plugin interface. I fetched it from the binutils.src.rpm, but I would assume it should become part of binutils-devel since it's a public API?

Thanks again!

Regards,

Tilmann

Comment 4 Nick Clifton 2011-04-11 11:25:16 UTC

Hi Tilmann,

  binutils-2.21.51.0.8-2.fc16 should fix the problem.  I have reverted my previous patch (which only enabled plugins for gold) and instead fixes the binutils.spec file to pass --enable-plugins to all of the tools that it builds, including gold, ld, nm and ar.

Cheers
  Nick

Comment 5 Tilmann Scheller 2011-04-11 19:56:33 UTC

Hi Nick,

I just tested the new build, works great!

I was able to successfully do an LTO build of clang with clang :)

Is there a chance that we can still get this into Fedora 15? E.g. with an update?

Regards,

Tilmann

Comment 6 Nick Clifton 2011-04-12 10:28:34 UTC

Hi Tilmann,

> Is there a chance that we can still get this into Fedora 15? E.g. with an
> update?

Sorry - I think not.  The sources are frozen except for blocker bug fixes and this is one of them.  It is also possible, although unlikely, that this change would break the building of some other package.  I don't think that this would happen, but I would rather not take the chance at this late stage of the release cycle.

Once the f15 release is final I will happily check in an update to apply this functionality.

Cheers
  Nick

Comment 7 Tilmann Scheller 2011-04-12 18:17:10 UTC

Hi Nick,

an update after the Fedora 15 release is perfectly fine :)

Regards,

Tilmann

Comment 8 Nick Clifton 2011-05-27 12:25:08 UTC

Hi Tilmann,

  Now that F15 is out of the door, I have checked in the patch to enable plugins.  Please try out binutils-2.21.51.0.6-3.fc15.

Cheers
  Nick

Comment 9 Ben Liblit 2012-07-25 22:30:34 UTC

I am unable to reproduce Tilmann's success from comment #5.  Tilmann, perhaps you can give more details about your working recipe?  Or perhaps this bug needs to be reopened?

I'm using Fedora 17 with the standard clang-3.0, llvm-3.0, and plugin-enabled binutils-2.22.52.1 RPMs.  I tried to compile a trivial "Hello, world!" program using clang, with intermediate objects generated as bitcode and link-time optimization at the end to produce the native code:

  % clang -flto -Wl,-plugin,/usr/lib/llvm/LLVMgold.so -o main main.c

This fails, reporting "File format not recognized" for the intermediate object file.  Saving that file with "-save-temps" confirms that it is LLVM bitcode, not native object code, as I expected thanks to the "-flto" flag.  Using "-v" I can see that "/usr/bin/ld" is receiving the "-plugin /usr/lib/llvm/LLVMgold.so" arguments.  I can even trace that with "strace" and confirm that the plugin is being loaded.  And yet the file format is not recognized.  Why not?  Why is the plugin-boosted linker not dealing with this correctly?