On Tue, May 26, 2020 at 2:13 PM Mike Gilbert <flop...@gentoo.org> wrote: > > On Tue, May 26, 2020 at 2:03 PM Alexis Ballier <aball...@gentoo.org> wrote: > > > > On Tue, 26 May 2020 10:45:39 -0400 > > Mike Gilbert <flop...@gentoo.org> wrote: > > > > Note that having the 'pic' useflag should be considered something > > > > to be fixed: rewrite the asm in a PIC way. But these days nobody > > > > has the will to do it since this is mostly an issue on x86+pax, > > > > both being slowly decreasing. > > > > > > Given that PaX has been stripped out of official Gentoo kernels due to > > > the grsecurity licensing issue, I wonder if there is any other good > > > reason to keep the "pic" USE flag today. Surely this affects a very > > > small population of users. > > > > > > I couldn't find any recent reference, but PIC shared libs used to be a > > QA policy. There's mainly two reasons to it: First is W^X enforcement; > > non PIC shared libs are refused by the x86_64 linker so a non-issue > > there, on x86 you need pax to emulate it because the mmu doesn't support > > the X part; I don't know about other arches. > > Then there is the small memory waste done because those libs will be > > loaded COW and thus their "code" is not shared anymore between > > processes. And the small startup performance hit to > > perform the relocations. > > > > The latter part affects everyone, and the rule of thumb for having a > > pic useflag (instead of always pic) is that the gain for non-pic asm is > > better than the loss of non-pic shared libs. This is subjective but > > usually a no-brainer for multimedia packages. > > Assuming that the pic performance penalty is really only relevant on > legacy arches (like x86), here are a couple of options: > > 1. Disable pic on arches where tie performance penalty is small. > 2. Force pic everywhere, performance be damned.
Option 1 should say "Disable pic on arches where the performance penalty is large."
