Wie funktioniert ein Linker?

CMosSwitcher Gast #1374822
Lesenswert?
• ▲
▼ 
Hallo,

ich habe eine sehr allgemeine Frage:
Wie funktioniert ein Linker?

Die Aufgabe von einem Linker ist mir klar. Er "linkt" Object Files oder 
Librarys in bestimmte Speichersegmente.

Globale Daten werden an bestimmte Adressen im RAM gelinkt.

Aber nun sieht der Aufruf bei meinem Linker etwas so aus:

Linker <options> OUTPUTFILE <linker file> <files>

Man kann entweder die Objectfiles die gelinkt werden sollen direkt im 
Linkerfile oder Linkerscript angeben, oder die Files die gelinkt werden 
sollen separat angeben.

Und genau das verstehe ich nicht! Warum kann man die Files auch separat 
angeben? Woher weiß dann der Linker in welches Segment welches Object 
File soll?

Würde es auch reichen nur das Linkerfile oder Linkerscript anzugeben???

Das man bei options so Sachen wie Map-File angeben kann ist jetzt net so 
wichtig, mir gehts nur um die grundlegende Funktion von so einem Linker.

Danke!!!

Lg
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Daniel D. Gast #1374848
Lesenswert?
• ▲
▼ 
Im Linker-Script wird ja festgelegt, wie die Sections der Object-Files 
zusammengefügt werden. Standardmäßig ist Code in .text und das 
Standard-Linker Script belässt es dabei (bei c mit gcc und ld. Bei c++ 
wird das vermutlich komplizierter sein). D.h. alles in .text der 
Object-Files landet in .text vom elf-File (bei der Windows-exe wirds 
ähnlich sein). Diese Zuordnung kann über ein nutzerdefiniertes 
Linker-Script geändert werden. Damit der Linker aber weiß, welche 
Dateien er überhaupt linken soll, müssen diese auf der Befehlszeile 
mitlaufen. Kann sein, dass man das auch übers Script machen kann, hab 
ich noch nie gebraucht...

VG, Daniel
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jörg W. Moderator Persönliche Seite #1374908
Lesenswert?
• ▲
▼ 
Der Dreh- und Angelpunkt, den du vermutlich noch nicht verstanden hast
dabei ist, dass der Linker sogenannte verschiebliche (englisch:
relocatable) Objektmoduln als Eingabe erwartet.  Diese haben an
allen Stellen, an denen später absolute Speicheradressen erwartet
werden, erst einmal eine Zahl stehen (0 oder ein Offset bezogen auf
den Anfang des Segments innerhalb des Moduls), zu dem dann noch ein
Verschiebe-Datensatz (relocation record) innerhalb des Objektmoduls
gehört.  Dieser Datensatz beschreibt, wie der Linker die tatsächliche
Adresse an der entsprechenden Stelle bilden soll.

Der Linker fügt dann die einzelnen Speicheranforderungen (Segmente)
der Objektmodule erst einmal zusammen.  Danach weiß er, welcher
Modul in welchem der Segmente welche Anfangsadresse bekommt bzw.
bei globalen Segmenten (Variablen) überlagert er diese an Hand der
gegebenen Namen (die sogenannten Symbole).  Danach kann er durch
alles noch einmal durch gehen und die Verschiebungen auflösen, indem
er die (nunmehr berechenbaren) absoluten Adressen einträgt.  Dabei
überschreibt er die vorher dort stehenden Werte dann mit den
tatsächlichen, d. h. der jeweilige Modul wird dabei nicht etwa
nachträglich länger (sonst könnte er ja vorher die Offsets nicht
berechnen).
Antwort Zitieren Bearbeiten Löschen Beitrag melden
CMosSwitcher Gast #1374992
Lesenswert?
• ▲
▼ 
@Daniel und Jörg

vielen Dank für die Erklärungen.

Was für eine Rolle spielt dann "link order" in diesem Zusammenhang?
Sollte es nicht egal sein in welcher Reihenfolge die Objectfiles gelinkt 
werden bzw. was für Adressen sie dann schlussendlich erhalten?

Nochmal zur Handhabung des Linkers:
Ich habe z.B. schon Linkerfiles gesehen da werden die ganzen 
Applikationsobjekte nacheinander aufgeführt.. also erst die Segment 
Angabe und dann alle Object untereinander.

Davon abgesetzt wird dann z.b. das Segement 0xFFC0 definiert und dann 
folgt die Angabe des Object mit der Vectortabelle.

Meiner Meinung nach macht es dann aber gar keinen Sinn zusätzlich zu dem 
Linkerfile die einzelnen Objekte als Kommandozeilen Parameter zu 
übergeben, oder? Sonst wäre ja auch die Angabe mit dem Segment 0xFFC0 im 
Linkerfile unnötig.

@Jörg

Wenn ich dich richtig verstanden habe, dann sind z.B. auch fertige 
Librarys verschiebbar, da sie sonst ja nicht universell auf 
verschiedenen Controllerplattformen (unterschiedliche Speicher) 
eingesetzt werden könnten.

Danke!!
Antwort Zitieren Bearbeiten Löschen Beitrag melden
(prx) A. K. #1374999
Lesenswert?
• ▲
▼ 
CMosSwitcher schrieb:

> Was für eine Rolle spielt dann "link order" in diesem Zusammenhang?
> Sollte es nicht egal sein in welcher Reihenfolge die Objectfiles gelinkt
> werden bzw. was für Adressen sie dann schlussendlich erhalten?

Philosophiefrage.

Es gibt Linker, die streng der Reihe nach arbeiten. Speziell bei 
Libraries merkt man das. Wenn an der Position in 
Kommandozeile/Steuerfile eine Funktion noch nicht gebraucht wird, wird 
sie nicht eingebunden, auch wenn später Bedarf bestünde. 
Unix/Linux-Linker arbeiten üblicherweise so.

Andere Linker wiederum arbeiten in mehreren Phasen und sammeln erst alle 
Informationen aller Files ein bevor sie die Abhängigkeiten auflösen.

> Wenn ich dich richtig verstanden habe, dann sind z.B. auch fertige
> Librarys verschiebbar

Libraries sind im Grunde nichts anderes als ein Archiv aus normalen 
Objektfiles, jedenfalls ist der Unix "ar" so entstanden. Eine das 
Verfahren vereinfachte Symboltabelle hat er erst später verpasst 
bekommen.

Auch fertige ausführbare Programme sind oft noch verschieblich, 
insbesondere bei DLLs / shared libs ist das unvermeidlich.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren