GNU Linker -o Option

Janvi Gast #4345640
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?)
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Jörg W. Moderator Persönliche Seite #4345674
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Janvi Gast #4345840
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Janvi Gast #4349414
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Rolf M. #4349471
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jörg W. Moderator Persönliche Seite #4349481
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Janvi Gast #4351477
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>
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Janvi Gast #4351525
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 (?)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren