W systemie 32-bitowym każdy proces ma praktycznie 2^32 bajty przestrzeni adresowej CONTIGUOUS. Dlaczego więc ostateczny kod wykonywalny wygenerowany przez linker musi być relokowalny. Jaki jest wymóg, ponieważ wszystkie wygenerowane adresy będą wirtualnymi adresami w przestrzeni adresowej własnego procesu, a inny proces NIE MOŻE ich używać. Dzięki temu proces można umieścić w dowolnym miejscu. Dlaczego można przenosić?Pamięć wirtualna i kod przemieszczalny
To musi być możliwe do przeniesienia, ponieważ aby wykonać proces, należy umieścić go w rzeczywistej pamięci głównej w gotowej kolejce. Teraz miejsce w pamięci głównej, które ma być umieszczone, nie jest ustalone (jest umieszczone wszędzie tam, gdzie dostępna jest wystarczająca ilość miejsca), więc rzeczywiste adresy instrukcji różnią się od jego adresu wirtualnego.
Stąd stwierdzenia wykonywania połączeń do funkcji, powraca etc muszą zostać odpowiednio zaktualizowane wskazując na rzeczywisty adres tych funkcji
Ale to będzie pod opieką MMU (moduł zarządzania pamięcią). Co ma z tym zrobić relokacja. – user1863877
Niektóre systemy operacyjne sprawiają wykonywalnego kodu relocatable (to zdecydowanie nie jest uniwersalny do wszystkich systemów operacyjnych) zezwól na address space layout randomization. Pomaga to złagodzić niektóre ataki.
W przeszłości, gdy stosy były wykonywalne, można było wykorzystać przepełnienie bufora, pisząc wykonywalny kod bezpośrednio na przepełnionym stosie lub sterty. Gdy systemy operacyjne stały się mądrzejsze i zaczęły uniemożliwiać wykonanie stosu i sterty, ataki stały się bardziej wyrafinowane i zaczęły używać znanych sekwencji kodu w pamięci, wykonując return oriented programming. Ograniczenie do tej klasy ataków zostało po raz pierwszy zrobione poprzez losowe rozmieszczenie pamięci dla bibliotek współdzielonych (ponieważ były one łatwiejsze do wykorzystania), a następnie, gdy atakujący przełączyli się na atakowanie głównego pliku wykonywalnego, przez losowanie pozycji pamięci w pliku wykonywalnym. Aby było to możliwe, główny plik wykonywalny musi być relokowalny.
Kod wykonywalny nie zawsze zawiera względne adresy. Na przykład w Windowsie adresowanie jest często bezwzględne (np. Dla danych globalnych).
Rozważ dwie różne biblioteki dynamiczne. Oba zostały skompilowane dla stałego adresu podstawowego 0x00100000. Twój program próbuje załadować oba z nich. Gdzie jest program ładujący, aby umieścić drugą bibliotekę DLL? Preferowany adres bazowy jest już używany przez inną bibliotekę DLL.
W tym przypadku relokowalny kod pomaga umieścić drugą bibliotekę DLL pod innym adresem i załatać wewnętrzne wskaźniki do nowej lokalizacji. Przy stałych adresach bazowych ładowanie drugiej biblioteki DLL byłoby po prostu nieudane.
sprawdź to: http: //stackoverflow.com/questions/7193888/load-time-relocation-and-virtual-memory – mohit