Time to reevaluate the cost of -fPIC?
Debian Policy requires the use of -fPIC for shared libraries, but
documents potential exceptions for libraries with position-dependent
assembly, and for libraries that would incur a significant performance
hit. We can't do anything automated about the former, only fix the
assembly. But regarding the latter, conventional wisdom advises that
-fPIC incurs a particularly high cost on x86-32, since it burns a
register across the whole program, of which the architecture has
precious few.
However, since GCC 5, that advice doesn't actually hold true anymore.
Quoting https://gcc.gnu.org/gcc-5/changes.html:
> Reuse of the PIC hard register, instead of using a fixed register, was
> implemented on x86/x86-64 targets. This improves generated PIC code
> performance as more hard registers can be used. Shared libraries can
> significantly benefit from this optimization.
While this doesn't make PIC absolutely free, it does eliminate almost
all of the cost, to the point that it no longer seems worthwhile to
build without -fPIC. Apart from that, building *all* code with -fPIC
(including both programs and libraries) helps with hardening.
With GCC 5 already the default as of the last stable release, I think
we may want to reevaluate the conventional wisdom. Perhaps this
information might help support the current iteration of any proposals to
adopt more hardening flags by default, for instance.
- Josh Triplett
Reply to: