Unterschied arm-none-eabi-gcc und arm-elf-gcc

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

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! :-/

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 ?)