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