Risky linkers

I don’t usually advertise much of what I do as a job for a living, and I’d like to keep it this way. It’s usually easy to guess when you look at what my commits are though; so for instance, when you see me committing new versions of net-proxy/squidclamav you can guess I’m working for proxy for the usual customer of mine. When you see me committing a version bump for sys-block/dd_rescue you guess I have a broken harddisk to recover data from, and so on.

Interpreting the stuff I’m committing around the tree for my latest job is probably quite tricky and will likely lead nowhere beside the need to get things cross-compiling correctly but that’s not something new, I have done it before. It might lead you a bit more when you think that I’m currently looking at working on getting packages to play nice with the gold linker. Yes the linker I criticised in many places.

Beside the fact that using the gold linker is required for what I’m working on, I have another interest in trying it out: it has neither the soft --as-needed behaviour, nor it seems to shut up if a symbol can be resolved in an indirect dependency (which is a behaviour shared with the Apple linker). This makes it particularly interesting for testing proper linking.

Now, I know a few people wondered why the gold USE flag was dropped from the tree ebuilds altogether; well it turns out that it’s quite disruptive still; this is what happens on the main tinderbox after rebuilding gold with gold itself:

tinderbox ~ # ld -v
Segmentation fault

Unfortunately I didn’t pay enough attention to this when I first tried it, so the result is that the 64-bit tinderbox is currently out of order and needs to be re-created from scratch. This is twice unfortunate because I didn’t back it up after setting it up, so it’s going to take quite a while before I can resume the 64-bit builds (for the 32-bit builds it’s going to take just a moment as I can simply download a safe binutils binary package).

Now, I’m sure there are working versions of gold – as I’m actually working with one on a separate container – but if I may, I still am a little concerned that, over two years after gold became the news, we still lack a version of it that is sufficiently stable to provide us with a daily-basis usable linker. Not that it says anything; I’m pretty sure that with the exception of developers, integrators, and Gentoo users, there is little interest in having a fast linker, so the fact that it doesn’t get much attention to be implemented in a timely fashion really doesn’t concern me as much. On the other hand, it shows that sometimes, even though rewriting everything from scratch in a different language can gain you a lot in better design, you still lose a lot in either flexibility or knowledge base that is still very important, and would regress if missed.

Anyway the bottom line for this is that I won’t be able to use the stricter gold for testing linking on the tinderbox, just like I cannot use --no-undefined or sneak -Werror-implicit-function-declaration into the compiler’s flags, even though all of those are pretty good devices to identify issues. Sigh!

4 thoughts on “Risky linkers

  1. That makes me wonder if wouldn’t make sense try to pick the good ideas in gold, learn from the implementation pitfalls and rewrite it in a safer language…

    Like

  2. I believe I heard somewhere that the standard linker on Fedora is a fork of GNU ld which has some of the same features as gold. I could be completely off-base here, because this is second hand, but it might be interesting to look into what they’ve got.

    Like

  3. Which version of binutils do you use? They’re about to make a release. If the bug yo see is in the rc, please tell them.

    Like

  4. Zeev the segfault seems to be fixed in the HEAD version and, likely, on the release candidate of the release (which seems to still be missing in tree, unfortunately).On the other hand I found “a different bug”:http://sourceware.org/bugzi… which is probably worse (it refuses a syntax allowed by the documentation of binutils itself!) and that upstream is not convinced to fix properly.As for Fedora; I seriously doubt they have a fork of GNU ld since… they mostly maintain GNU ld. They tend to apply over some changes to default behaviour so that it actually have some behaviour shared with gold (and that’s something that we also do, just not at that point), but that’s about it, for what I know.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s