Re: Time to reevaluate the cost of -fPIC?
On Wed, May 04, 2016 at 12:41:25AM +0200, Matthias Klose wrote:
> On 03.05.2016 22:50, Josh Triplett wrote:
> > 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.
>
> No, GCC 5 is not part of jessie.
Misreading of https://packages.debian.org/gcc; skimmed through the
versions too quickly.
Nonetheless, GCC 5 is available in current testing and unstable, and
this optimization will apply to the next stable release, so I think the
point still holds.
> Did you intend to speak about -fPIE instead of -fPIC?
No, I was referring to -fPIC, though for an executable -fPIE would be
more appropriate. I would hope the same optimization applies there too.
- Josh Triplett
Reply to: