Moin zusammen, kann mir bitte einer aus der Runde in drei Sätzen den Unterschied zwischen arm-none-eabi-gcc und arm-elf-gcc erklären? Habe hier auch noch nichts auf die schnelle gefunden, suche aber weiter. Ich würde morgen früh gerne bescheid wissen. Beste Grüße Ingo
Ich bin untröstlich, dass ich nicht früher antworten konnte. Das none-eabi ist für sogenannte bare-metal builds (statisch gelinkt, monolithisches OS/App.) gedacht, während das elf-gcc davon ausgeht, dass die übersetzte Applikation unter (Linux/)ELF läuft, d.h. von einem OS geladen wird. -- Marcus
Marcus Harnisch schrieb: > Ich bin untröstlich, dass ich nicht früher antworten konnte. Das > none-eabi ist für sogenannte bare-metal builds (statisch gelinkt, > monolithisches OS/App.) gedacht, während das elf-gcc davon ausgeht, dass > die übersetzte Applikation unter (Linux/)ELF läuft, d.h. von einem OS > geladen wird. Diese Unterscheidung ist mir bisher noch nicht begegnet. Gibt es eine Quelle dazu? Man kann sicher auch eine "old"-ABI toolchain nutzen, um sogen. bare-metal Applikationen zu bauen. GCC arm-eabi target ist relativ neu, arm-elf gab es vorher schon lange und ist m.W. "old"-ABI. Es gibt auch Linux-Umgebungen mit EABI ("Kernel build with EABI") und wohl auch Unterstützung für beides "Old"-ABI und EABI. (Habe bisher selbst nur mit älteren "OABI"-buildroots gearbeitet, also dafür nicht aus erster Hand zu bieten.) Von einem Zusammenhang der ABI und dem ELF-Format habe ich bis dato noch nichts gelesen - dafür auch eine Quelle bitte? Man kann sicher eine Datei im ELF-Format auch mit "OABI"-code füllen und das wurde auch schon vor EABI nicht nur für Linux-Umgebungen gemacht. Spezielle Einstellungen zum Erstellen von Linux-Anwendungen kenne ich eher in Cross-Toolchains für arm-linux-Targets, was m.W. bestenfalls mittelbar mit der ABI und dem ELF-Format zu tun hat. Lasse mich gerne eines Besseren belehren. Ausführliches Dokument, das die Unterschiede erklärt kenne ich auch keines. Zumindest EABI ist auf arm.com gut dokumentiert, da es ein von ARM gepushter "Standard" zur Verbesserung der Austauschbarkeit von object-code ist. Mglw. noch ergänzend brauchbar (wenn auch knapp): http://www.oesf.org/index.php?title=Q3:_What_are_OABI_and_EABI%3F
Tut mir leid, habe gerade etwas zu weit gedacht (BPABI usw.). Selbstverständlich kann man ELF Objekte erzeugen und verarbeiten, ohne ein OS zu verwenden. Es scheint in der Tat so zu sein, dass arm-elf-gcc das old-ABI beschreibt und nicht zwingend von einem OS ausgeht. In diesem Fall würden sich none-eabi und elf-gcc tatsächlich nur durch die ABI Version unterscheiden. Gruß Marcus
bin durch diesen Thread hier gelandet Beitrag "Problem mit Include Pfade" und offensichtich scheint das ein cywin Problem zu sein weil ich ein ausgefallene gcc Version haben wozu ich am besten und einfachsten mal auf einen neuen Compiler (Codesourcery/Mentor) umsteige. Bislang hies mein GCC (gcc.exe für Cortex) auch "elf-gcc" und natürlich habe ich für den Debugger (der dann auch flasht) damit Dateien im ELF Format mit eingebauter Debug-Info erzeugt. Wenn ich das richtig sehe, kann man mit der none-eabi aber auch elf erzeugen, was von der Namensgebung nicht gerade logisch scheint. Noch weniger leuchtet mir ein, woher das "none" vor dem eabi kommt. Bedeutet dies, daß bei ABI (von ARM definiert?) nicht fertig gelinkt wird, weil ein Loader vom Betriebssystem zum Ladezeipunkt noch endgültige Adressen einsetzen muß (ähnl. windows exe file) während bei eabi (emedded abi) davon ausgegangen wird, daß der Code unverschiebbar im Flash liegt? Warum dann aber "none-eabi"? Möglicherweise hat das der Loader von meinem Debugger bislang einfach alles richtig gemacht aber es wäre u.a. zur Auswahl eines Compilers trotzdem nützlich die wirkliche Funktionsweise zu durchschauen
:
Bearbeitet durch User
Ohne wirklich durch deinen Beitrag durchzuschauen (was hat Cygwin mit der Benamung der Toolchain zu tun?): 1) "none" bezieht sich nicht auf "eabi" sonder auf das OS. 2) Namen sind Schall und Rauch.. wenn ein Vendor, keine Lust auf das Namensschema hätte, dann nutzt er es eben nicht. 3) Allgemein das Namensschema (imho und bei Stackoverflow gefunden): [Plattform]-[Vendor]-[OS]-[ABI-Variante] Gruß Dennis P.S.: Jetzt habe ich das Thread-Ausgraben auch noch unterstützt! :-/
:
Bearbeitet durch User
besten Dank - leuchtet ein. Cygwin hat im Prinzip nichts mit der Namensgebung zu tun nur bin ich in meinem Fall halt dadurch auf diesen Thread gekommen weil mir nicht klar war nach welcher gcc Version ich für mich suchen muß damit ich auf meinem Cortex-M3 was zum laufen kriege. Noch was wo mich speziell zu Codesourcery ziemlich wundert: Mit der (kostenlosen) Lite Version wird jede Menge Java Geraffel und Verzeichnisse (offensichtlich für Eclipse/gdb) angelegt. Die Workbench selbst scheint aber ohnehin nicht nuztbar zu sein weil gebührenpflichtig. Also müsste man das alles löschen können (?) Damit aber nicht genug - die vom Installer angelegte Verzeichnis-Struktur ist weiter undurchsichtig. Der Compiler ist gleich mehrmals in verschiedenen Verzeichnissen erreichbar z. Bsp. unter ..\gcc\arm-none-eabi\bin\gcc.exe sowie aber auch unter ..\gcc\bin\arm-none-eabi-gcc.exe in identischer (?) Version mit den Runtime libs ist es ähnlich undurchsichtig: ..\gcc\lib\4.8.1\thumb2\ sowie aber auch unter ..\gcc\arm-none-eabi\lib\thumb2\ in identischer (?) Version Einmal mit libc und einmal mit libgcc. Neben thumb2 gibt es noch thumb und armv6-m wo mir die Unterschiede auch nicht klar sind und ich nur raten kann. Weil mein cortex-m ja zu armv7-m gehört muss armv6-m wohl falsch sein. Wie wird dann aber die Lib für eine HW-FloatingPoint unterschieden und welche libs wären für den A8? Die Sourcen der libs sind wohl nicht dabei. Ist das bei anderen Toolchains die auf gcc aufsetzen auch nicht ? (raisonance, atollic, coocox ?)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.