Gast
#5893782
Frage steht ja schon im Titel. Werden die am Ende einfach als Adressen übersetzt?
Hängt von der Programmiersprache, Plattform, Compiler/Interpreter und -Einstellungen ab.
Gast
#5893809
Wo kann man sowas denn genau nachlesen? Würde mich interessieren wie das bei der Sprache C ist, mit GCC.
Polohemd schrieb: > Wo kann man sowas denn genau nachlesen? In der Spezifikation des Ausgabeformats, also z.B. ELF, COFF, PE... Polohemd schrieb: > Würde mich interessieren wie das > bei der Sprache C ist, mit GCC. Der Programmcode (Instruktionen) greift auf Variablen und Sprungziele (Funktionen) nur über Adressen zu, d.h. der Code an sich funktioniert ganz ohne Text-basierte Namen. Programmdateien können aber Debug-Informationen und/oder Symboltabellen enthalten, welche den Adressen Namen geben. Der dynamische Linker nutzt die namensbasierten Symboltabellen um Funktionen und Variablen in dynamischen Bibliotheken (DLL, SO) zu finden.
Wozu soll so etwas im Executeable abgespeichert werden. Namen sind - im wahrsten Sinne des Wortes - Schall und Rauch. Das gilt auch für Nichtraucher. Für den Compiler ist es nur wichtig, an welcher Adresse eine Variable oder eine Funktion rumhängt. Mehr nicht! Es erfolgt dann ein Sprung auf die Adresse XYZ oder der Zugriff auf die Variable, die an der Stelle ABC liegt.
Ich vergaß: Oft weis nicht mal der Compiler wo was ist, sondern erst der Linker.
Gast
#5893850
Sebastian S. schrieb: > Ich vergaß: > Oft weis nicht mal der Compiler wo was ist, sondern erst der Linker. ...der seinerseits die Relocation-Infos vom Compiler bekommt. Aber du hast insofern recht, die endgültigen Adressen erzeugt erst der Linker (mithilfe der relativen Adressen, die vom Compiler kommen).
Polohemd schrieb: > Wo kann man sowas denn genau nachlesen? Würde mich interessieren wie das > bei der Sprache C ist, mit GCC. https://www.gnu.org/software/gcc/ https://gcc.gnu.org/onlinedocs/gccint/ https://sourceware.org/binutils/docs-2.32/
Gast
#5893923
Erwin D. schrieb: > Aber du hast insofern recht, die endgültigen Adressen erzeugt erst der > Linker (mithilfe der relativen Adressen, die vom Compiler kommen). Nichtmal das ist immer wahr. Es kann nämlich noch eine weitere Runde Relokation passieren, beim Laden des Binary in den Arbeitsspeicher. Und das aus unterschiedlichen Grunden. Einmal natürlich das normale dynamische Linken gegen andere Binaries. Und dann solche Sicherheitsfeatures wie ASLR.
Gast
#5894059
c-hater schrieb: > Es kann nämlich noch eine weitere Runde > Relokation passieren, beim Laden des Binary in den Arbeitsspeicher Und auch das sind nur virtuelle Adressen, die wahre physikalische Adresse weiss nur die MMU. Georg
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.