Czy 32-bitowy kod x86 musi być specjalnie skompilowany z PIC dla współdzielonych plików biblioteki?

Question

Kompilowanie kodu do pliku obiektowego musi być wykonywane niezależnie od pozycji, jeśli plik obiektowy ma być załadowany jako biblioteka współdzielona (.so), ponieważ podstawowy adres wirtualny, do którego jest ładowany plik obiektu współdzielonego w różnych procesach, może być różne.

Teraz nie wystąpiły błędy podczas próby załadowania pliku .so skompilowanego i połączonego bez opcji -fpic GCC na 32-bitowych komputerach x86, podczas gdy nie powiedzie się na 64-bitowych komputerach x86.

Losowe stron internetowych znalazłem, że nie muszę -fpic na 32bit ponieważ kod skompilowany bez -fpic prac przez przypadek według 32bit X86 ABI również, gdy są wykorzystywane w sposób niezależny od pozycji. Ale nadal znajdowałem oprogramowanie, które dostarczane jest z oddzielnymi wersjami bibliotek w 32-bitowych wersjach: jedna dla PIC i jedna dla innych niż PIC. Na przykład kompilator intel jest dostarczany z libirc.a i libirc_pic.a, ten ostatni jest kompilowany w trybie niezależnym od pozycji (jeśli chcemy połączyć ten plik .a w plik .so).

Zastanawiam się, jaka jest dokładna różnica między używaniem -fpic i nie używanie go dla kodu 32-bitowego i dlaczego niektóre pakiety, takie jak kompilator intel, nadal są dostarczane z oddzielnymi wersjami bibliotek?

Answer 1

bazy adresów wirtualnych, że plik wspólny cel został załadowany do różnych procesów może inaczej

Ponieważ obiekty udostępnione zazwyczaj ładuje się preferowanym adres mogą pojawić działa poprawnie . Ale fPIC jest dobrym pomysłem dla wszystkich wspólnych kodów.

Uważam, że powodem, dla którego często nie ma dwóch wersji biblioteki, jest to, że wiele dystrybucji używa domyślnie dla wszystkich kodów fPIC.

Answer 2

Nie jest tak, że kod non-PIC działa "przez przypadek" na x86 (32-bitowy). Jest to, że dynamiczny linker dla x86 obsługuje niezbędne "textrels" potrzebne do jego działania. Dzieje się to przy bardzo dużym koszcie zużycia pamięci i czasu uruchamiania, ponieważ zasadniczo cały segment kodu musi być załatany podczas ładowania (i tym samym staje się pamięcią nie do współużytkowania).

Twórcy dynamicznego linkera twierdzą, że biblioteki współużytkowane inne niż PIC nie mogą być obsługiwane na architekturze x86_64 z powodu podstawowych problemów architektury (natychmiastowe przesunięcia adresu nie mogą być większe niż 32-bitowe), ale problem ten można łatwo rozwiązać po prostu zawsze ładując biblioteki w pierwszych 4gb wirtualnej przestrzeni adresowej. Oczywiście kod PIC jest bardzo niedrogi na x86_64 (PIC nie jest tak wydajnym zabójcą, jak na 32-bitowym x86), więc prawdopodobnie mają rację, aby go nie obsługiwać i uniemożliwić głupcom tworzenie bibliotek non-PIC ...