Forum: Compiler & IDEs GNU Linker -o Option


von Janvi (Gast)


Lesenswert?

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

von Clemens L. (c_l)


Lesenswert?

--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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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

von Janvi (Gast)


Lesenswert?

> 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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Janvi schrieb:
> dass ich binutils gar nicht brauche. Offensichtlich sind aber doch
> etliche nützliche Dinge dabei

Klar, ein Linker beispielsweise. :-))

von Janvi (Gast)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Janvi (Gast)


Lesenswert?

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>

von Janvi (Gast)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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
Noch kein Account? Hier anmelden.