habe ein Projekt in welchem ich ld mit der Option -o .\out.elf aufrufe. LD macht ein ELF/DWARF File welches inklusiv Debuginformation prima funktioniert. (Zielsystem STM32) Nun möchte ich Firmware-updates verschicken, welche mit einem ST-Link geflasht werden sollen. Der kann aber nur Intel-Hex bzw. binär oder S19, ausserdem ist es gar nicht beabsichtigt. den Quellcode über die Debuginformation herzugeben. Wie lauten die Optionen zum (gleichzeitigen?) Erzeugen von anderen Codeformaten ohne Debuginfo ? (a.out ist binär?)
--oformat=xxx Eine Liste der unterstützen Formate gibt es mit "arm-none-eabi-objdump -i". (Ist "man arm-none-eabi-ld" so schwierig?)
:
Bearbeitet durch User
Janvi schrieb: > ausserdem ist es gar nicht beabsichtigt. den Quellcode über die > Debuginformation herzugeben Machst du auch nicht, es würden nur die Hinweise auf den Quellcode mit herausgegeben. Normalerweise erzeugt man solche zusätzlichen Ausgabedateien über das Kommando "objcopy" aus dem regulären ELF-File:
1 | arm-none-eabie-objcopy -O ihex inputfile.elf outputfile.hex |
> Ist "man arm-none-eabi-ld" so schwierig?
habe in "using ld" von Chamberlain und Taylor erfolglos gesucht
und war bislang der Meinung, dass ich binutils gar nicht brauche.
Offensichtlich sind aber doch etliche nützliche Dinge dabei.
Besten Dank
Janvi schrieb: > dass ich binutils gar nicht brauche. Offensichtlich sind aber doch > etliche nützliche Dinge dabei Klar, ein Linker beispielsweise. :-))
Bislang war ich der Meinung, das ld und as gar nicht zu den binutils gehören (https://sourceware.org/binutils/docs/binutils/index.html) was aber wohl etwas vorschnell gewesen ist. Dafür gehört wohl make nicht zu binutils. Meine GCC Verison habe ich von hier (ohne make aber mit objcopy): https://launchpad.net/gcc-arm-embedded und dabei landen die Dateien gleich 2 mal auf der Platte. Einmal mit der Bezeichnung arm-none-eabi im Dateinamen und einmal im Suchpfad. Die Dateilängen sind (falls doppelt) exakt gleich, die Anzahl der Dateien in den Verzeichnissen aber unterschiedlich. Weis jemand warum das so ist ? Ausfuehrliche Version von C:\GNU_ARM\bin 12.11.2015 12:22 <DIR> . 12.11.2015 12:22 <DIR> .. 21.09.2015 19:10 664.064 arm-none-eabi-addr2line.exe 21.09.2015 19:10 687.616 arm-none-eabi-ar.exe 21.09.2015 19:10 1.128.960 arm-none-eabi-as.exe 21.09.2015 19:10 1.634.304 arm-none-eabi-c++.exe 21.09.2015 19:10 662.528 arm-none-eabi-c++filt.exe 21.09.2015 19:10 1.632.768 arm-none-eabi-cpp.exe 21.09.2015 19:10 34.304 arm-none-eabi-elfedit.exe 21.09.2015 19:10 1.634.304 arm-none-eabi-g++.exe 21.09.2015 19:10 1.631.744 arm-none-eabi-gcc-4.9.3.exe 21.09.2015 19:10 51.200 arm-none-eabi-gcc-ar.exe 21.09.2015 19:10 51.200 arm-none-eabi-gcc-nm.exe 21.09.2015 19:10 51.200 arm-none-eabi-gcc-ranlib.exe 21.09.2015 19:10 1.631.744 arm-none-eabi-gcc.exe 21.09.2015 19:10 1.308.160 arm-none-eabi-gcov.exe 21.09.2015 19:10 4.837.376 arm-none-eabi-gdb-py.exe 21.09.2015 19:10 4.692.992 arm-none-eabi-gdb.exe 21.09.2015 19:10 723.968 arm-none-eabi-gprof.exe 21.09.2015 19:10 950.272 arm-none-eabi-ld.bfd.exe 21.09.2015 19:10 950.272 arm-none-eabi-ld.exe 21.09.2015 19:10 673.280 arm-none-eabi-nm.exe 21.09.2015 19:10 820.736 arm-none-eabi-objcopy.exe 21.09.2015 19:10 1.014.272 arm-none-eabi-objdump.exe 21.09.2015 19:10 687.616 arm-none-eabi-ranlib.exe 21.09.2015 19:10 410.624 arm-none-eabi-readelf.exe 21.09.2015 19:10 664.576 arm-none-eabi-size.exe 21.09.2015 19:10 664.064 arm-none-eabi-strings.exe 21.09.2015 19:10 820.736 arm-none-eabi-strip.exe 21.09.2015 19:10 142 gccvar.bat 28 Datei(en), 30.715.022 Bytes die Sparversion unter C:\GNU_ARM\arm-none-eabi\bin 12.11.2015 12:22 <DIR> . 12.11.2015 12:22 <DIR> .. 21.09.2015 19:10 687.616 ar.exe 21.09.2015 19:10 1.128.960 as.exe 21.09.2015 19:10 950.272 ld.bfd.exe 21.09.2015 19:10 950.272 ld.exe 21.09.2015 19:10 673.280 nm.exe 21.09.2015 19:10 820.736 objcopy.exe 21.09.2015 19:10 1.014.272 objdump.exe 21.09.2015 19:10 687.616 ranlib.exe 21.09.2015 19:10 820.736 strip.exe 9 Datei(en), 7.733.760 Bytes
Janvi schrieb: > Bislang war ich der Meinung, das ld und as gar nicht zu den binutils > gehören > (https://sourceware.org/binutils/docs/binutils/index.html) was aber wohl > etwas vorschnell gewesen ist. Dafür gehört wohl make nicht zu binutils. Klingt doch auch logisch. Die Binutils sind die Tools, die mit Binaries (im Sinne von Bibliotheken oder Programmen) arbeiten. Sie haben also alle gemeinsam, daß sie irgendwelche .o oder .a oder .hex oder derlei öffnen und oder erzeugen müssen. make hat damit überhaupt nichts zu tun. Der Linker dagegen ist das zentrale Element, um das herum die anderen binutils aufgebaut sind. Ohne Linker und Assembler ist der gcc nutzlos, ohne make nicht. > Weis jemand warum das so ist ? Vermutlich, weil Windows immer noch nicht richtig mit Symlinks umgehen kann.
:
Bearbeitet durch User
Rolf M. schrieb: > Vermutlich, weil Windows immer noch nicht richtig mit Symlinks umgehen > kann. Bzw. Hardlinks, als solche werden sie unter unixoiden Systemen gehandhabt:
1 | % find /usr/local -inum 447692 |
2 | /usr/local/bin/arm-none-eabi-ld.bfd |
3 | /usr/local/bin/arm-none-eabi-ld |
4 | /usr/local/arm-none-eabi/bin/ld.bfd |
5 | /usr/local/arm-none-eabi/bin/ld |
Das sind alles Verweise auf das gleiche Binary.
Habe versucht den Compileraufruf durch eine dritte Kopie zu vereinfachen. Path zeigt darauf mit c:\Programme\gcc\ aber der Aufruf klappt im Gegensatz zum Original der Kopie nicht (Sorry für das OT) Liegt das daran, dass gcc seinerseits selbst wieder versucht as und ld aufzurufen ? C:\data\cad\job\swagelok\fw>dir main.c Volume in Laufwerk C: hat keine Bezeichnung. Volumeseriennummer: 80FD-3D05 Verzeichnis von C:\data\cad\job\swagelok\fw 16.08.2015 20:00 37.812 main.c 1 Datei(en), 37.812 Bytes 0 Verzeichnis(se), 811.572.146.176 Bytes frei C:\data\cad\job\swagelok\fw>gcc gcc: fatal error: no input files compilation terminated. C:\data\cad\job\swagelok\fw>gcc -c main.c gcc: error: CreateProcess: No such file or directory C:\data\cad\job\swagelok\fw>\Programme\gcc\bin\arm-none-eabi-gcc -c main.c C:\data\cad\job\swagelok\fw>\Programme\gcc\gcc -c main.c gcc: error: CreateProcess: No such file or directory C:\data\cad\job\swagelok\fw>
ok - wenn ich den Pfad auf c:\Programme\gcc\bin\ (anstelle ohne ..\bin\) richte kann ich die exe auch umbenennen und es funzt. Dortselbst ist die exe dann auch noch 2x vorhanden, einmal mit und einmal ohne Versionsnummer im Dateinamen. Den vorinstallierten Pfad c:\Programme\gcc\bin\arm-none-eabi\bin darf man aber inkl. Inhalt weder umbenennen noch löschen sonst geht sofort nichts mehr. Offensichtlich werden dort auch die exe neben lib (stdio.h usw) benutzt. Solangs geht braucht mans glaub auch nicht verstehen warum (?)
Ich verstehe leider Bahnhof. Nochmal: lass den Linker (vom Compiler gesteuert) ein ganz normales ELF-File bauen. Anschließend wirfst du arm-none-eabi-objcopy an, und erzeugst aus diesem ein Intel-Hex-File (oder Motorola-SRecord) als Kopie der ELF-Datei. Argumente siehe oben. Diesen Weg begehen seit Jahren Generationen von AVR-Programmierern.
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.