GCC Linker File

[J. V. (janvi)]

bin gerade dabei ein STM32 Projekt auf den Launchpad GCC umzubiegen. 
Hierbei gibt es folgendes Problem beim Linken:

C:\data\fw>arm-none-eabi-ld -T linkfile.ld -Map=file.map --cref -gc-sections -o out.elf
arm-none-eabi-ld: no input files

Im linkfile.ld ist aber angegeben:

INPUT (
    cpuinit.o
    flop.o
    main.o
    misc.o
    startup_stm32f10x_ld.o
    stm32f10x_adc.o
    stm32f10x_dma.o
    stm32f10x_flash.o
    stm32f10x_gpio.o
    stm32f10x_it.o
    stm32f10x_rcc.o
    stm32f10x_tim.o
)

Die Objektdateien existieren auch tatsächlich und wenn ich sie beim 
Aufruf des Linkers in der Kommandozeile anstelle dem Linkerfile angebe, 
werden sie sogar korrekt gelinkt.

[Bernd K. (prof7bit)]

Warum willst du sie im linkerscript angeben? Das ist ziemlich 
unkonventionell. Normalerweise hat man ein einmal ausgetüfteltes 
linkerscript für den Controller und das benutzt man dann unverändert für 
alle Projekte. Objektdateien gibt man üblicherweise an der Kommandozeile 
an.

[Markus F. (mfro)]

Das kann man grundsätzlich schon so machen (auch wenn's nicht üblich 
ist).

Die unter "INPUT" aufgeführten Files ersetzen die sonst auf der 
Kommandozeile übergegebenen Objekt- und Library-Files.

Allerdings muss man sich klar machen, dass die Angabe auf der 
Kommandozeile und die Angabe in einem mit -T angegebenen Linker-Script 
trotzdem was fundamental anderes ist.

Wenn kein -T angegeben ist, wird mit dem default Linker script (das der 
Linker "im Bauch hat") gelinkt.
Wird ein eigenes Linker-Script mit -T angegeben, **ersetzt** dieses das 
Eingebaute (das dann natürlich nicht mehr abgearbeitet wird).

Das default Linker script kriegt man mit ld --verbose zu sehen. Das
 dürfte ein wenig komplexer sein als deine o.a. paar Zeilen.

Wenn man das "-T" weglässt und das Linker-Script wie ein Objektfile auf 
der Kommandozeile angibt, **ergänzt** es das Default-Script anstatt es 
zu ersetzen.

C:\data\fw>arm-none-eabi-ld linkfile.ld -Map=file.map --cref -gc-sections -o out.elf

sollte das Ding eigentlich zum Fliegen bringen.

[J. V. (janvi)]

> sollte das Ding eigentlich zum Fliegen bringen.

ja, es scheint der eigentliche Grund für das Versagen zu sein. Im 
eigenen ld stehen ausser dem Input aber noch ein paar andere Dinge drin 
und da krachts dann dafür:

C:\data\fw>arm-none-eabi-ld  linkfile.ld -Map=file.map --cref -
gc-sections -o out.axf cpuinit.o flop.o main.o misc.o startup_stm32f10x_ld.o stm
32f10x_adc.o stm32f10x_dma.o stm32f10x_flash.o stm32f10x_gpio.o stm32f10x_it.o s
tm32f10x_rcc.o stm32f10x_tim.o
arm-none-eabi-ld: warning: linkfile.ld contains output sections; did you forget
-T?
arm-none-eabi-ld: section .isr_vector loaded at [080018a0,080019ab] overlaps sec
tion .data loaded at [080018a0,080018a3]
arm-none-eabi-ld: warning: cannot find entry symbol _start; defaulting to 080000
00
C:\data\fw>

Vielleicht bleibe ich doch besser bei den Files in der Kommandozeile was 
dann auch den Vorteil hat, dass die Quellfiles nur einmal im makefile 
stehen und bei Änderungen nicht auch noch im ld nachgeführt werden 
müssen. Habe da aber noch in Erinnerung vor vielen Jahren mal mit einer 
255 Byte Puffergröße für die Parameterübergabe reingefallen zu sein was 
dann die hinteren Filenamen ohne Vorwarnungen abgeschnitten hat.

Wahrscheinlich ist es vorteilhaft, sich an die ld Beispiele von 
Launchpad zu halten anstelle welche neu zu erfinden.

[Johann L. (gjlayde)]

J. V. schrieb:
> Im linkfile.ld ist aber angegeben:

Sicher, dass du wirklich ein Linker Description File willst und nicht 
ein @file Option File?  Mit @file werden Kommandozeilen-Optionen aus 
file gelesen.

[J. V. (janvi)]

> Sicher, dass du wirklich ein Linker Description File willst

ja, steht im Anhang. Die Projekte wurden auf einer Hitop IDE 
eingerichtet,  welche auch das ld (teilw. automatisch als temporäres 
File) für den arm-hitex-elf-gcc erzeugt hat. Als vor 10 Jahren die STM32 
gestartet haben, war das eine der wenigen verfügbaren Möglichkeiten. Der 
Hitex-GCC hat aber eine besch. bis gar keine Runtime, die IDE hat 
Probleme unter W7 und auch der Debugger flasht keine F2 oder F4 usw. 
weshalb es Zeit wird auf die Launchpad Version bzw. auch ein Segger 
Kabel oder ST-Link umzusteigen. Mit Coocox &Co tu ich mich wegen der 
Unabhängigkeit noch etwas schwer, weshalb ich den manuellen Abkürzer 
(Umweg) über das Tal der Tränen gewählt habe.

Alleine Suchpfad und Lib habe ich (wegen Ungültigkeit bzw. da sowieso 
nicht benutzt) auskommentiert.

[Markus F. (mfro)]

Da stimmt was mit den Kommentaren nicht ...

[Johann L. (gjlayde)]

J. V. schrieb:
> Im linkfile.ld ist aber angegeben:

Wenn ich's recht sehe, ist das .ld eine auto-generierte Datei deiner 
alten IDE (Hitex). Die 1:1 auf einer anderen IDE (Launchpad) zu 
verwenden geht spätestens dann schief, wenn die alte IDE was anderes 
generiert hätte, z.B. aufgrund anderer Projekteinstellungen, Modulnamen, 
etc.

Entweder die neue IDE bringt entsprechende Magie zum Generieren eines 
passenden .ld (eher unwahrscheinlich) oder du musst den Build-Prozess an 
die neue IDE anpassen — inclusive sinnvollem, nicht von Modulnamen und 
Pfaden abhängiger Linker Description.

[Johann L. (gjlayde)]

J. V. schrieb:

/****************************************************************************
Portables GCC Linker Script

/*SEARCH_DIR("C:\Programme\Hitex\GnuToolPackageCortex\bin\..\lib\gcc\arm-hitex-elf\4.4.0\thumb2\soft" )

INPUT (
   .\objects\cpuinit.o
.\objects\flop.o

Da werden in Zeile 1 und 4 /* Kommentare geöffnet aber nicht beendet.

Und anstatt "Portables GCC Linker Script" sollte eher ein "Automatically 
generated file, do not edit" stehen.  Dieses .ld ist nämlich alles 
andere als portabel wegen

-- expliziter Dateinamen
-- explititer (Such)Pfade
-- \ als Pfad-Trenner
-- C: als Laufwerk

[J. V. (janvi)]

> in Zeile 1 und 4 /* Kommentare geöffnet aber nicht beendet

Das war der Grund warum die nachfolgende INPUT Section nicht 
funktioniert hat. Eine neue IDE gibt es (bislang) nicht und von 
Launchpad ist nur der GCC welcher selbst keine Linkfiles erzeugen kann. 
Deshalb habe ich für den ersten Anstatz mal das alte Linkfile von der 
bisherigen IDE rauskopiert um einen funktionierenden Ausgangspunkt zu 
haben. Der Eingangskommentar war natürlich ursprünglich ein anderer und 
das was ich daraus gemacht habe das Ziel der Aktion. Aber schon beim 
auskommentieren des Pfads passiert es dann...

Zumindest funktioniert es jetzt mal und ich habe sogar verstanden was 
ich falsch gemacht habe. Darüber hinaus macht es absolut Sinn, die 
Modulnamen in das Makefile und nicht ins Linkerfile reinzupacken. Wie es 
aussieht, ist das Linkerfile auch stark mit dem Startup-Code in der 
Namensgebung verstrickt und das was in den Projekten ist, wurde 
ursprünglich von den Cortex-A auf die Cortex-M umgebogen, so dass ich da 
im Projekt auch noch nicht so weit bin. Aber es linkt ja schon und kann 
damit immer nur noch normaler werden.

[Jim M. (turboj)]

Man will übrigens bei ARM den LD nicht direkt als Linker aufrufen, 
sondern man nimmt GCC auch zum Linken und übergibt ihm dabei auch den 
CPU Typ.

Hintergrund dabei ist die LibC normalerweise als Multilib dabei liegt, 
also für verschiedene CPU Typen jeweils eigene Dateien. Dann muss sich 
der Linker die korrekte raussuchen, und das kann er wenn GCC als 
Frontend benutzt wird.

[Janvi (Gast)]

Die von ARM beigelegten conf Dateien sind für mich
hoffnungslos unverständlich. Momentan rufe ich GCC pro C Quelle einmal 
und den as pro Assembler Quelle einmal auf.
Man könnte GCC auch einmal aufrufen und alle C Quellen als
Liste von Dateien mitgeben. Es dauert dann aber mitunter etwas lange
bis wieder ein Echo angezeigt wird.
Beim letzten GCC Aufruf -c weglassen und dazu dann die Link Optionen
mit -Wl dazu angeben ?