Page MenuHomeFreeBSD

Build toolchain components as dynamically linked executables by default
ClosedPublic

Authored by dim on Oct 16 2019, 8:34 PM.

Details

Summary

Historically, we have built toolchain components such as cc, ld, etc as
statically linked executables. One of the reasons being that you could
sometimes save yourself from botched upgrades, by e.g. recompiling a
"known good" libc and reinstalling it.

In this day and age, we have boot environments, virtual machine
snapshots, cloud backups, and other much more reliable methods to
restore systems to working order. So I think the time is ripe to flip
this default, and link the toolchain components dynamically, just like
almost all other executables on FreeBSD.

Maybe at some point they can even become PIE executables by default! :)

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

dim created this revision.Oct 16 2019, 8:34 PM
kib accepted this revision.Oct 16 2019, 9:04 PM
This revision is now accepted and ready to land.Oct 16 2019, 9:04 PM

Maybe at some point they can even become PIE executables by default! :)

What's holding this up btw? Is there any actual reason why we have any non-PIE executables at all on aarch64 and amd64?

dim added a comment.Oct 18 2019, 12:07 PM

Maybe at some point they can even become PIE executables by default! :)

What's holding this up btw? Is there any actual reason why we have any non-PIE executables at all on aarch64 and amd64?

The MK_PIE knob was added in a "default NO" state in rS344179 by @emaste on 2019-02-15, so it has been in there for a while. Probably nobody ran extensive tests yet with it enabled? The commit itself also has a few remarks on why certain executables do not yet have PIE enabled. I also remember there were some people posting issues with PIE and ASLR on the mailing lists, which may have been solved by now.

jilles added a subscriber: jilles.Oct 18 2019, 1:04 PM

Historically, another reason was performance. For example, https://svnweb.freebsd.org/base?view=revision&revision=76801 which changed make(1) to be statically linked states performance as the reason.

Since the performance gain of static linking is in exec, exit, fork and calls across library boundaries, I imagine the gain is limited for a compiler or linker that uses considerable CPU time by itself but for things like make installworld a static make might be significantly faster.