Unterschied "arm-elf-gcc" und "gcc"

Der gcc erzeugt direkt Code für deinen aktuellen PC, arm-elf-gcc für 
arm.
Weil der Aufruf (Optionen, Dateien) gleich ist, gibt es dafür keine 
extra man-page (cross compiler).

Wobei es nicht nur um die nackte Codeerzeugung geht, sondern auch wo 
Headerdateien gesucht werden, welche Libs dazu verwendet werden etc..
Daher auch ggf. noch einmal die Unterscheidung arm-elf... und 
arm-linux... oder ähnliche.

tobi schrieb:

> ich bin verwirrt:
> Wo liegt der Unterschied zwischen dem arm-elf-gcc und dem gcc ??

arm-elf-gcc ist der übliche Name für einen GCC, der als Crosscompiler
für ARM-Targets mit dem (veralteten) ABI namens "elf" konfiguriert
worden ist.

> Wo liegen also die Unterschiede, ist der arm-elf-gcc eine abgespeckte
> Version speziell für ARM-Arch. ?

Nicht "abgespeckt", sondern "anders konfiguriert".  Warum sollte ein
ARM denn weniger Speck brauchen als ein X86?

> Und wieso heißt der eig. arm-ELF-gcc? => erzeugt der auch hex-files
> dirket zum flashen ?

Nein, der erzeugt Assembler-Dateien, die der Assembler zu verschieb-
lichen Objektdateien (im ELF-Format) assembliert, die der Linker in
(nicht verschiebliche) ausführbare ELF-Dateien umbaut.  Daraus kann
ein Tool names objcopy (oder arm-elf-objcopy) dann den Inhalt auch
entnehmen und in eine Binär- oder Intel-Hex-Datei auslagern.

Das aktuelle ABI ist aber das sogenannte EABI, die Tools fangen dann
üblicherweise mit arm-none-eabi- an (also arm-none-eabi-gcc usw.).

Jörg Wunsch schrieb:
> üblicherweise mit arm-none-eabi-

... wobei das "none" sich nicht auf eabi bezieht, sondern auf das 
jeweilige Ziel-Betriebssystem, bzw. in diesem Fall eben keines.

Klaus Wachtler schrieb:

> ... wobei das "none" sich nicht auf eabi bezieht, sondern auf das
> jeweilige Ziel-Betriebssystem, bzw. in diesem Fall eben keines.

Ja, allerdings ist mir nicht klar, warum das nun plötzlich auftaucht
(und diese unsäglich langen Namen erzeugt); bei arm-elf-gcc ist es
auch einfach weggelassen worden, insofern wäre arm-eabi-gcc passender
gewesen.

ach stell dich nicht an - das ist halt der Fortschritt :-)

ELF kannst du nicht fälschen :-)

Ich kennen nur avrdude zum Fälschen, aber der will von ELF nichts 
wissen.
Ich glaube auch nicht, daß andere Fälscher das anders machen.

Aus der man avrdude:

1

Input files can be provided, and output files can be written in different file formats, such as raw binary files containing the data to download to the chip, Intel hex format, or Motorola S-record format. There are a number of tools available to produce those files, like asl() as a standalone assembler, or avr-objcopy() for the final stage of the GNU toolchain for the AVR microcontroller.

Klaus Wachtler schrieb:
> Ich glaube auch nicht, daß andere Fälscher das anders machen.

Doch, meiner Meinung nach kann OpenOCD ELF direkt lesen, und auch
AVR Studio (zumindest die letzten 4er Versionen).  AVRDUDE sollte
das eigentlich auch mal lernen, ist aber eine Frage der verfügbaren
Zeit.

Ach, wozu?
Von Hand ruft man das eh nicht alles auf, sondern über ein makefile 
o.ä..

Jörg Wunsch schrieb:
> Klaus Wachtler schrieb:
>> Ich glaube auch nicht, daß andere Fälscher das anders machen.
>
> Doch, meiner Meinung nach kann OpenOCD ELF direkt lesen, und auch
> AVR Studio (zumindest die letzten 4er Versionen).

Je nach Backend kann das auch der gdb, z. B. mit st-util/stlink v2.