Hallo, ich bin verwirrt: Wo liegt der Unterschied zwischen dem arm-elf-gcc und dem gcc ?? beim aufruf des linux manuals [code}man arm-elf-gcc [/code] komm ich auf die gcc-man-seite ! Wo liegen also die Unterschiede, ist der arm-elf-gcc eine abgespeckte Version speziell für ARM-Arch. ? Und wieso heißt der eig. arm-ELF-gcc? => erzeugt der auch hex-files dirket zum flashen ? grüße
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.
OK, danke erst einmal. Die Konvertierung in ein Binärformat ist zwingend erforderlich oder kann das ELF-format direkt gefalscht werden ?
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.