Fragen zur Funktionsweise von GCC
-
Hi,
ich bereite gerade ein referat für die Schule vor und da die Funktionsweise von Compilern ein teil davon ist habe ich mir den Artikel zu GCC in Wikipedia durchgelesen. Ich verstehe fast alle Schritte aber einige Fragen habe ich doch noch:
Weiter unten ist ein Schema zu sehen welches die einzelnen Schritte zeigt:
1. Was geschieht beim "relocate"?
2. Warum werden bereits die Objektdateien als Kernelmodule oder Archive verwendet? Müssen die nicht vorher auch noch gelinkt werden?
3. Was ist der unterschied zwischen einem Archiv und einem Shared Obeject?
4. Warum muss nach dem Kompilieren noch einmal extra Assembliert werden? Ist das der schritt indem der produzierte Assambler Code auf die jeweilige Plattform übersetzt wird?
5. Beim linken werden doch ebenfalls Programmbibliotheken in das Programm eingebunden oder?Gruß, Prophet05
-
Kann mir den wirklich keiner meine Fragen beantworten?
-
Nein.
-
zu 1. Also was GCC unter "relocate" versteht kann ich dir nicht genau sagen. Ich kenne das hauptsächlich in folgendem Zusammenhang: wenn du ein Programm kompilierst, gibt es Adressen, die noch nicht bekannt sind (also ihr absoluter Wert), weil sie davon abhängig sind, an welcher Adresse die Anwendung zur Laufzeit geladen wird. Und genau zu diesem Zeitpunkt werden diese Adressen dann "relocated".
zu 2. Was meinst du denn mit Kernelmodulen? Der Quellcode wird vom Compiler übersetzt und in Objektdateien gespeichert. Ob das schon konkreter Maschinencode oder eine Art binärer Zwischencode ist, kann man sicherlich irgendwo in der Doku zum GCC nachlesen. Und diese Objektdateien werden gelinkt, um daraus Executables, also ausführbare Dateien, zu erzeugen.
zu 3. google ist dein Freund. Ein bisschen Eigeninitiative solltest du schon zeigen.
zu 4. Mit Assembler Code kann eine CPU nunmal nichts anfangen. Es ist im Grunde nur ein Zwischenschritt auf dem Weg zum fertigen Kompilat. Ob dieser durchgeführt wird oder ein anderer, vllt. direkterer Weg benutzt wird, hängt zudem vom Compiler ab. GCC übersetzt wohl erstmal in Assembler und macht daraus dann die Objektdatei.
zu 5. Ja.
-
Ergänzend:
zu 1.
(Zumindest unter Linux) kenne ich das ein bisschen anders: Wenn man nicht gerade Techniken benutzt die vor Pufferüberläufen o.ä. schützen, wird die Anwendung zur Laufzeit immer an dieselbe (virtuelle) Adresse geladen. Deshalb muss beim Linken bereits relocated werden, um die relativen Adressen im Object in absolute Adressen innerhalb des ausführbaren Programms umzuwandeln. Denn vor dem Linken steht ja noch nichtmal fest in welcher Reihenfolge die Objekte ins Binary kommen.zu 2.
Der Linux-Kernel ist bereits ein gelinktes "Programm". Hier werden die ladbaren Module als reine Objekte gespeichert und zur Laufzeit des Programms (Kernel) direkt geladen. Dabei wird beim Laden des Moduls relocated. Das Laden eines Kernelmoduls ist quasi ein Linken zur Laufzeit (nicht zu verwechseln mit dynamischem Linken von Shared Objects).zu 4.
Der Assembler-Code ist lediglich eine für Menschen lesbare Schreibweise des Maschinencodes. Sprich Wörter (Mnemonics) statt Bytes. Da verschiedene CPUs auch verschiedene Befehlssätze und Register haben, ist bereits der Assemblercode plattformabhängig.
-
@LordJaxom
zu 1. Ja, das wird unter Win32/64 wohl auch nicht anders sein, da dort der Speicherzugriff ebenfalls virtuell ist. Halt Protected bzw. Long Mode. Ich bin mir zwar nicht sicher, aber "Relocation" beim Linken dürfte dort nicht immer ausreichen, zB wenn dynamische Bibliotheken verwendet werden. Ergänzend, das ist letztendlich auch nicht so entscheidend, wann es passiert. Ob nun beim Linken (Windows, Linux) oder beim Laden (DOS) der Anwendung. Das Prinzip ist das gleiche.
-
Vielen dank für eure antworten! Ihr habt mir sehr weitergeholfen!