1 |
On Wed, 2003-12-10 at 18:07, Aron Griffis wrote: |
2 |
> I think it's important all developers see this, so I'm forwarding it to |
3 |
> gentoo-core and gentoo-dev... (I'm referring to the text from Daniel, |
4 |
> not necessarily the fact that I screwed up ;-) |
5 |
|
6 |
Thanks Aron :) |
7 |
|
8 |
Just to give some context, we were talking about situations where a line |
9 |
this is needed to get an ebuild to compile on non-x86 arches: |
10 |
|
11 |
append-flags -fPIC |
12 |
|
13 |
Here is what you need to know about situations like this: |
14 |
|
15 |
1) If you need to add append-flags -fPIC to get something to compile, |
16 |
the Makefile is broken for all arches including x86. This is true *even |
17 |
if* it seems to compile and run OK without -fPIC on x86. Here's why. |
18 |
|
19 |
2) If it needs an -fPIC to compile on a non-x86 arch, it actually also |
20 |
needs -fPIC on x86 -- not to get the thing to compile correctly of |
21 |
course but for another reason: to avoid wasting memory when the code is |
22 |
used. Non-PIC library code on x86 wastes memory when used, even though |
23 |
it technically "works". The dynamic loader is forced to create a private |
24 |
copy for each process using the non-PIC code, defeating one of the main |
25 |
reasons of using shared libraries in the first place -- to conserve RAM. |
26 |
|
27 |
3) The proper solution for things that need -fPIC is to create a patch |
28 |
for the Makefiles to add -fPIC to only those sources that specifically |
29 |
need it (shared library source onlt), send the patch upstream, and then |
30 |
have the ebuild apply it for *all* arches, not just the non-x86 arches. |
31 |
This does 2 things: |
32 |
|
33 |
a) gets the code to compile on non-x86 systems |
34 |
b) makes the code run with optimal memory usage on x86 systems |
35 |
|
36 |
append-flags -fPIC is a band-aid that gets the program to work, but |
37 |
isn't an optimal fix. Why can't we just enable -fPIC globally? Because |
38 |
you may be enabling it for non-shared-lib code. Compiled PIC code uses |
39 |
up an extra machine register for storing a memory offset. This means |
40 |
that by globally enabling -fPIC, you will be hurting performance for |
41 |
things that don't need relocatable code by causing an extra machine |
42 |
register to be unecessarily used. (According to pipacs, it is rumored |
43 |
that amd64 has some new addressing mode that allows PIC code to be just |
44 |
as efficient as non-PIC code, although he has not confirmed this yet.) |
45 |
|
46 |
(Incidentally, you may have noticed that some 'l33t' shared libraries |
47 |
purposely use non-PIC code on x86 -- I think ffmpeg may be one such lib |
48 |
-- by doing this, they are trying to gain one extra machine register, |
49 |
and are willing to pay the price of forcing each process to have their |
50 |
own personal copy of the shared library in RAM for the sake of the extra |
51 |
performance they can squeeze out of having that extra register.) |
52 |
NVIDIA's OpenGL libraries appear to do this on x86. On AMD64 they do not |
53 |
(probably because non-PIC .so's on AMD64 appear to be illegal.) |
54 |
|
55 |
The vast majority of this info comes from pipacs, who is working with |
56 |
the hardened team on security stuff. It's amazing what you can learn |
57 |
from a low-level assembly programmer in a couple of hours :) |
58 |
|
59 |
Regards, |
60 |
|
61 |
Daniel |