Czy nadal trzeba używać -fPIC podczas kompilacji z GCC?

Question

Na komputerach docelowych gcc, gdy ktoś chciał skompilować bibliotekę współużytkowaną, musiałby podać -fpic lub -fPIC, aby poprawić działanie. Wynika to z faktu, że domyślnie używane było adresowanie bezwzględne, które nadaje się do plików wykonywalnych, które mają pełną kontrolę nad własną przestrzenią adresową, ale nie dzielą się bibliotekami, które mogłyby być ładowane w dowolnym miejscu w przestrzeni adresowej pliku wykonywalnego.

Jednak współczesne jądra wdrażają teraz randomizację przestrzeni adresowej, a wiele nowoczesnych architektur obsługuje adresowanie względne komputera. Wszystko to sprawia, że ​​adresowanie bezwzględne nie nadaje się do użytku (randomizacja przestrzeni adresowej) lub niepotrzebne (adresowanie względne komputera osobistego).

Zauważyłem również, że klang nie ma opcji -fPIC, co czyni mnie rzeczą, która nie jest już potrzebna.

Czy więc -fpic jest teraz zbędny, czy trzeba wygenerować osobne pliki .o, jeden do korzystania z biblioteki statycznej i jeden do korzystania z biblioteki współdzielonej?

Answer 1

Nigdy nie trzeba generować oddzielnych plików .o. Zawsze określaj opcje kompilatora do generowania kodu przenośnego (zazwyczaj -fPIC).

W niektórych systemach kompilator może być skonfigurowany do wymuszania tej opcji lub do jej domyślnego ustawienia. Ale i tak nie zaszkodzi to określić.

Uwaga: Istnieje nadzieja, że ​​w miejscu, w którym adresowanie z komputera jest obsługiwane, , i działa dobrze, to znaczy, że -fPIC używa tego trybu zamiast dedykować dodatkowy rejestr.

Answer 2

Zgadzam się z wami w wielu przypadkach -fPIC/-fPIC opcje są prawie zbędne, ja jednak z nich korzystać, aby zapewnić:

• przenoszenia (nie jestem pewien, co szczególnie OS/kernel będzie dostępny)
• wsteczną kompatybilność z tych opcji: gwarantuje to zachowanie, które chcesz na starszych jąder
• zwyczaj - twarde rzeczy złamać :)
• zgodność ze starszymi codebases które mogą wymagać jej

Answer 3

Nadal trzeba kompilować z opcją -fPIC. Problem nie jest rozwiązywany za pomocą adresowania komputerowego. Problem polega na tym, w jaki sposób rozwiązujesz zewnętrzne symbole. W dynamicznie połączonym programie rozdzielczość jest zgodna z różnymi regułami, a zwłaszcza z randomizacją przestrzeni adresowej, której nie można rozwiązać w czasie połączenia.

A clang ma flagę -fPIC podobnie jak gcc.

$ cat > foo.c 
void foo(void); 
void bar(void) { foo(); } 
$ gcc -S foo.c && grep call.*foo foo.s 
    call foo 
$ gcc -fPIC -S foo.c && grep call.*foo foo.s 
    call foo@PLT 
$ clang -S foo.c && grep call.*foo foo.s 
    callq foo 
$ clang -fPIC -S foo.c && grep call.*foo foo.s 
    callq foo@PLT 
$ 

Answer 4

gcc cele nie nadążają z platform i architektur, a nie wszystkie z nich obsługuje natywnie PIC jak architektura x86 robi. W niektórych przypadkach tworzenie PIC oznacza dodatkowy narzut, który może być niepożądany, a który chcesz lub potrzebujesz, zależy to od twojego projektu i platformy, na którą celujesz.

Answer 5

To zależy od celu. Niektóre cele (takie jak x86_64) są domyślnie niezależne od pozycji, sp -fpic to odbiór i nie ma wpływu na wygenerowany kod. W takich przypadkach można go pominąć i nic się nie zmienia. Inne obiekty docelowe (takie jak 32-bitowe wersje x86) nie są domyślnie niezależne od położenia, więc w przypadku tych maszyn, jeśli pominiesz -fpic dla pliku wykonywalnego, wyłączy on ASLR dla tego pliku obrazu (ale nie dla bibliotek współdzielonych, których używa).