This Time Self-Hosted
dark mode light mode Search

Gold rush — The troubles of using gold for testing

In my previous post I have listed a few good things that come with the stricter behaviour implemented by the gold linker, and why I’d like to use this for testing. You also know that the current released versions are definitely unreliable and unusable for testing (or any other) purposes.

Well, version 2.20 (which is the latest “stable” release of binutils) is quite ancient by now, and indeed, 2.21 is coming out soon, so I actually went on to test the status of gold in that version: it works, sort-of. Indeed, with the current working version of gold, that, among other things, can – and I’d venture to say should – be built separately, you can build a good deal of packages. But by no mean all.

It’s not just a matter of what fails because of the underlinking prevention of which, I hope, I have conveyed the positive effects and the reasons why we should enforce it more strongly, but rather of the fact that we know for a fact of at least one bug where gold fails to execute properly when correctly using the documented syntax.

The above bug is a split-up of the issues that fuse itself has when built with gold: from one side there was a bug in fuse (the same symbol listed in two version names within the linker script), and that was fixed upstream; on the other hand, the following syntax, described by the binutils manual itself:

__asm__(".symver original_foo,foo@");

This is supposed to declare the symbol foo in the base version; it is not replaceable with a linker script either since there is no way to define the base version in there if any other version is defined. On the other hand, gold has gone up to now without implementing the feature. Willingly. And it’s actually not an entirely bad reason why it has been doing so: the reference implementation for this stuff (GLIBC) Is broken in this regard.

Indeed, it seems like, instead of actually using the base version first when a symbol without version is provided, GLIBC prefers another symbol, not even the default symbol — most likely, it depends on the order of the symbols in the ELF file. The result is, at any rate, pretty bad, because the binary compatibility between version 2.0 and all the following ones, for what concerns FUSE, is not really present: binary compatibility is ensured only since they started providing versioned symbols, so from version 2.2 onward.

Now, how to move forward from here depends vastly on whether version 2.21 will have the bug fixed or not; if not, then I think the only way out to solve this would be to install a separate gold package, installing a binutils-config configuration file to select it as default linker — this one is a nice trick, whose idea I lifted directly from the chromiumos-overlay binutils ebuild.

Indeed, using a separate ebuild would also help if we were to find some other problem with gold, failing to build or producing bad results for a package; I’m pretty sure that if my tinderbox would run with gold, it would be the big deployment it would need to be called “usable”. Yes I know there are other projects using it, but given there are still relatively big issues like the one I pictured above, I expect that it wasn’t really polished around enough yet. This would probably take care of it.

Comments 5
  1. I was under the impression that 100% compatibility to GNU ld is not a goal for gold. They don’t want to support some old stuff or things they consider bad design ideas.If that’s true, gold will have to provide enough advantages that distributions use it for 95%, GNU ld for the rest and there’s pressure on the last projects to change their code.

  2. I’m pretty sure they referred to the frontend implementation (so for instance @gold@ does not accept complex linker scripts like @ld@ does), but having a further incompatible link editor, without _used_ features of @ld@ is going to be so stupid a move that I wouldn’t even bother. On the other hand, as I said, I think the problem here is just that it wasn’t really tested with the massive amount of packages that Gentoo can provide tests for.

  3. Thinking about this, maybe the best way to get is to use alternatives mechanism. Oh, well…

  4. Yes, and we have way to implement that — @binutils-config@The problem is mostly that if even fixes with patch provided take weeks and weeks to apply because upstream is not sure whether it should provide a featureful link editor, then we’re stuck with something that won’t work on the long term, full stop.

  5. If I understand correctly there is no way to install both gnu ld and gold?I’m a developer and I will be very happy if I can use gold for my projects and gnu ld system wide.So if you start to implement this I can help by testing if you need such help 🙂

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.