O ile wiem, kod zespołu x86 jest bardzo ograniczony przez ograniczoną liczbę rejestrów.

Kiedy dowiedziałem się, że w Linuksie, aby utworzyć plik .so, trzeba podać argument -fPIC wiersza polecenia dla gcc, aby utworzyć kod niezależny od pozycji, nie mogłem w to uwierzyć.

O ile wiem, format pliku elf obsługuje relokacje, podobnie jak - w moich oczach znacznie lepiej - działa system DLL Windows: W systemie Windows linker przenosi wszystkie przesunięcia w bibliotekach DLL, jeśli jest to konieczne.

Myślę, że czas potrzebny na załadowanie pliku SO lub pliku DLL, a także ilość pamięci używanej do przechowywania plików .so w innym miejscu nie jest tak zła, jak brak całego rejestru, co wskazuje na GOT i wszystkie te skoki pośrednie.

W ogóle nie dbam o ALSR itp. W przypadku aplikacji, które mam na myśli, ponieważ zależy mi tylko na optymalizacji kodu w bibliotece.

1) Dlaczego Linux nie obsługuje bardziej dynamicznego ładowania bibliotek, jak Windows, który powinien produkować znacznie bardziej wydajny kod?

Jak dotąd nie znalazłem prawdziwego wyjaśnienia. Takie rzeczy mogą być bardzo kiepskie i powolne w przenoszeniu kodu (oczywiście, aby załadować edytor tekstu na komputerze stacjonarnym, liczy się szybkość jego ładowania, w pełni to akceptuję. Ale dla intensywnie obliczeniowego procesu serwera ( nie przetwarzając szkodliwych danych z Internetu), chciałbym mieć całą wydajność i rejestry, które mogę dostać!

2) Czy mogę stworzyć NIE-fPIC skompilowane pliki SO na Linuksie? Czy mogę po prostu zostawić -fPIC? Czy jest jakiś howto, podręcznik lub projekt, który działa na ten temat i pozwala nie marnować całego rejestru i nadal dynamicznie ładować biblioteki?

Co się stanie, jeśli po prostu upuszczę -fPIC podczas kompilowania pliku .so?