Soweit ich weiß, ist der x86-Assemblycode durch die begrenzte Anzahl von Registern stark eingeschränkt.

Als ich unter Linux erfuhr, dass zum Erstellen einer .so-Datei das Befehlszeilenargument -fPIC für gcc angegeben werden muss, um positionsunabhängigen Code zu erstellen, konnte ich es zunächst nicht glauben.

Soweit ich weiß, unterstützt das elf-Dateiformat Verschiebungen, genau wie das - in meinen Augen viel bessere - Windows-DLL-System: Unter Windows verschiebt der Linker alle Offsets in den DLLs, falls dies erforderlich ist.

Ich denke, dass die Zeit, die zum Laden einer SO- oder DLL-Datei benötigt wird, und auch die Menge an Speicher, die verwendet wird, um unterschiedlich verschobene .so-Dateien zu speichern, nicht so schlimm ist wie das Fehlen eines ganzen Registers, das immer darauf hinweist die GOT und mit all diesen indirekten Sprüngen.

Ich interessiere mich auch überhaupt nicht für ALSR usw. für die Anwendungen, an die ich denke, da es mir nur darum geht, Code in einer Bibliothek so weit wie möglich zu optimieren.

1) Warum unterstützt Linux kein dynamischeres Laden von Bibliotheken wie Windows, das viel leistungsfähigeren Code erzeugen sollte?

Bisher habe ich keine wirkliche Erklärung dafür gefunden. Nur ein paar Dinge wie das. Es wäre so schlecht und langsam, Code zu verlagern. (Natürlich spielt es beim Laden eines Textverarbeitungsprogramms auf einem Desktop-Computer eine Rolle, wie schnell es geladen wird. Aber für einen rechenintensiven Serverprozess ( Ich möchte alle Leistungen und Register haben, die ich bekommen kann!

2) Kann ich unter Linux NICHT-fPIC kompilierte SO-Dateien erstellen? Kann ich das -fPIC einfach weglassen? Gibt es ein Howto, Handbuch oder Projekt, das zu diesem Thema funktioniert und es ermöglicht, nicht ein ganzes Register zu verschwenden und trotzdem Bibliotheken dynamisch zu laden?

Was passiert, wenn ich das -fPIC beim Kompilieren einer .so-Datei einfach fallen lasse?