AVR-Gcc Kompiliervorgehensweise

Gerrit B schrieb:

> ich frage mich, ob der AVR-Gcc direkt den C oder C++ Code in das
> Binärprogramm übersetzt oder der Code erst in Assembler übersetzt wird
> um dann von dort aus mit einem schon vorher vorhandenen Compiler
> Kompiliert wird.
>
> Wenn zweiteres zutrifft, ist es möglich den Assembler-Code abzufangen?

Genaugenommen ist avr-gcc kein Compiler, sondern lediglich ein 
Treiber-Programm, das abhängig von den übergebenen 
Kommandozeilen-Argumenten andere Programme aufruft:

cc1: Der "eigentliche" C-Compiler, ein Text->Text-Transformator, der 
präprozessierten C-Code in Assembler umwandelt.

cc1plus: Ditto, für C++.

Hier enden die Tools von GCC. Die folgenden gehören nicht zum Projekt 
"GNU Compiler Collection (GCC)", sondern zu "GNU binutils":

as: Assembler -> angegebene Object-Format, hier elf32-avr.

ld: Linkt Objekte und Bibliotheken zum fertigen Programm (auch 
elf32-avr)

Welche Subtools mit welchen Optionen aufgerufen werden sieht man mit -v

Compilieren entspricht dem "main.c" -> "main.s" in der angehängten 
Grafik [1].  main.s ist ausgegraut, weil es ebenso wie die 
präprozessierte Quelle main.i (in der Grafik nicht gezeigt) nur temporär 
erstellt und nach Gebrauch wieder automatisch entfernt wird.

Damit diese Entfernen unterbleibt, gibt man -save-temps an oder 
compiliert nur ohne zu assemblieren, d.h. man gibt -S an.

Um die Assembler-Ausgabe mit weiteren Informationen anzureichern, gibt 
es -fverbose-asm, dp, -dP und noch weitere Optionen, die aber eher für 
GCC-Entwickler gedacht sind.

Es gibt nur wenige Fälle, in denen der Compiler kein Text sondern 
Binärcode erzeugt.  Solch ein Fall sind Präcompiled Header (PCH), die 
gcc erstellt, wenn man eine h-Datei "compiliert". Resultat ist eine 
.h.gch

Und es gibt auch Fälle, wo die Eingabe des Compilers kein Text ist. 
Beispiele sindPCH oder lto.  lto wird dabei wie eine eigene Sprache 
behandelt.

[1]
http://www.mikrocontroller.net/articles/Datei:Gcc-flow.svg