GCC -fPIC-Option

Question

Ich habe über GCC's Optionen für Code-Generierungskonventionen gelesen, aber ich habe nicht verstanden, was "Positionsunabhängigen Code generieren (PIC)" bedeutet. Bitte geben Sie mir ein Beispiel, um zu erklären, was das bedeutet.

Answer 1

Position Independent Code bedeutet, dass der generierte Maschinencode nicht davon abhängig ist, an einer bestimmten Adresse platziert zu sein, um zu funktionieren.

Zum Beispiel würden Sprünge als relative und nicht als absolute generiert werden.

Pseudo-Assembly:

PIC: Dies würde funktionieren, egal ob der Code sich an Adresse 100 oder 1000 befindet.

100: VERGLEICHE REG1, REG2
101: SPRUNG_BEI_GLEICH AKTUELL+10
...
111: NOP

Non-PIC: Dies funktioniert nur, wenn der Code sich an Adresse 100 befindet.

100: VERGLEICHE REG1, REG2
101: SPRUNG_BEI_GLEICH 111
...
111: NOP

ÄNDERUNG: In Antwort auf den Kommentar.

Wenn Ihr Code mit -fPIC kompiliert wird, ist er für die Einbindung in eine Bibliothek geeignet - die Bibliothek muss in der Lage sein, von ihrer bevorzugten Speicheradresse an eine andere Adresse verschoben zu werden, möglicherweise befindet sich bereits eine andere Bibliothek an der Adresse, die Ihre Bibliothek bevorzugt.

Answer 2

Ich werde versuchen, das bereits Gesagte auf einfache Weise zu erklären.

Immer wenn eine gemeinsam genutzte Bibliothek geladen wird, ändert der Loader (der Code auf dem Betriebssystem, der jedes von Ihnen ausgeführte Programm lädt) einige Adressen im Code, je nachdem, wo das Objekt geladen wurde.

In dem obigen Beispiel wird die "111" im nicht-PIC-Code das erste Mal vom Loader geschrieben, als es geladen wurde.

Für nicht freigegebene Objekte möchten Sie dies möglicherweise so belassen, da der Compiler einige Optimierungen für diesen Code vornehmen kann.

Für freigegebene Objekte, wenn ein anderer Prozess zu diesem Code "verlinken" möchte, muss er ihn an die gleichen virtuellen Adressen lesen oder die "111" ergibt keinen Sinn. Aber dieser virtuelle Speicherplatz kann bereits im zweiten Prozess belegt sein.

Answer 3

Code, das in gemeinsame Bibliotheken eingebettet ist, sollte normalerweise positionsunabhängigen Code sein, so dass die gemeinsame Bibliothek problemlos an (mehr oder weniger) jeder Adresse im Speicher geladen werden kann. Die -fPIC-Option stellt sicher, dass GCC einen solchen Code erzeugt.

Answer 4

Weiter hinzufügen...

Jeder Prozess hat denselben virtuellen Adressraum (Wenn die Randomisierung der virtuellen Adresse durch Verwendung eines Flags im Linux-Betriebssystem gestoppt wird) (Weitere Einzelheiten Deaktivieren und erneut aktivieren der Adressraumlayout-Randomisierung nur für mich)

Wenn es sich also um eine ausführbare Datei ohne gemeinsame Verknüpfung handelt (hypothetisches Szenario), können wir immer derselben asm-Anweisung dieselbe virtuelle Adresse ohne Schaden zu verursachen zuweisen.

Aber wenn wir ein gemeinsam genutztes Objekt mit der ausführbaren Datei verknüpfen möchten, sind wir uns nicht sicher über die Startadresse, die dem gemeinsam genutzten Objekt zugewiesen wird, da dies von der Reihenfolge abhängt, in der die gemeinsam genutzten Objekte verknüpft wurden. Dies bedeutet, dass die asm-Anweisung innerhalb der .so-Datei immer eine andere virtuelle Adresse haben wird, abhängig vom Prozess, mit dem sie verknüpft ist.

Ein Prozess kann also der .so-Datei im eigenen virtuellen Speicher eine Startadresse von 0x45678910 zuweisen, während ein anderer Prozess zur gleichen Zeit eine Startadresse von 0x12131415 zuweisen kann und wenn sie nicht die relative Adressierung verwenden, funktioniert die .so-Datei überhaupt nicht.

Deshalb müssen sie immer den relativen Adressierungsmodus und daher die fpic-Option verwenden.

Answer 5

Eine kleine Ergänzung zu den bereits veröffentlichten Antworten: Nicht als positionsunabhängig kompilierte Objektdateien sind verschiebbar; sie enthalten Einträge in der Relokationstabelle.

Diese Einträge ermöglichen es dem Loader (dieser Codeabschnitt, der ein Programm in den Speicher lädt), die absoluten Adressen umzuschreiben, um sie an die tatsächliche Ladeadresse im virtuellen Adressraum anzupassen.

Ein Betriebssystem wird versuchen, eine einzelne Kopie einer "Shared Object Library", die im Speicher geladen ist, mit allen Programmen gemeinsam zu nutzen, die mit derselben Shared Object Library verknüpft sind.

Da der Code-Adressraum (im Gegensatz zu Abschnitten des Datenspeichers) nicht zusammenhängend sein muss und weil die meisten Programme, die mit einer bestimmten Bibliothek verknüpft sind, einen ziemlich festen Bibliotheksabhängigkeitsbaum haben, gelingt dies meistens. In den seltenen Fällen, in denen es Abweichungen gibt, kann es erforderlich sein, zwei oder mehr Kopien einer Shared Object Library im Speicher zu haben.

Offensichtlich wird jeder Versuch, die Ladeadresse einer Bibliothek zwischen Programmen und/oder Programminstanzen zu randomisieren (um die Möglichkeit der Erstellung eines ausnutzbaren Musters zu reduzieren), solche Fälle häufiger auftreten lassen, nicht selten, also sollte man, wo ein System diese Funktion ermöglicht hat, jeden Versuch unternehmen, alle Shared Object Libraries so zu kompilieren, dass sie positionsunabhängig sind.

Da auch Aufrufe in diese Bibliotheken aus dem Hauptprogramm heraus verschiebbar gemacht werden, ist es viel unwahrscheinlicher, dass eine Shared Library kopiert werden muss.