ARM .o liste erstellen.

[Sebastian___ (Gast)]

Hallo,
ich habe zum testen ein kleines Projekt mit einem ARM (M33) Kern und
Benutze ThreadX + USBX mit CDC und etwas Kleinkram.
Irgendwann ist jetzt durch die vielen Files im Linker der Puffer im 
Windows übergelaufen.

USBX_pcdc_ra6e1.elf: $(OBJS) $(USER_OBJS) $(LINKER_SCRIPT) makefile $(OPTIONAL_TOOL_DEPS)
  @echo 'Building target: $@'
  @echo 'Invoking: GNU ARM Cross C Linker'
  arm-none-eabi-gcc -mcpu=cortex-m33 -mthumb -mfloat-abi=hard -mfpu=fpv5-sp-d16 -O2 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -Wunused -Wuninitialized -Wall -Wextra -Wmissing-declarations -Wconversion -Wpointer-arith -Wshadow -Wlogical-op -Waggregate-return -Wfloat-equal  -g -T "fsp.ld" -Xlinker --gc-sections -L "D:\\Projekte\\Renesas\\USBX_pcdc_ra6e1\\e2studio/script" -Wl,-Map,"USBX_pcdc_ra6e1.map" --specs=nano.specs --specs=rdimon.specs -o "USBX_pcdc_ra6e1.elf" -Wl, --start-group $(OBJS) $(USER_OBJS) $(LIBS) -Wl,--end-group
  @echo 'Finished building target: $@'
  @echo ' '

Das Problem ist $(OBJS) $(USER_OBJS) $(LIBS). Das wird bei vielen Files 
so lang das Windows streikt.

make (e=87): Falscher Parameter.

 ist das Ergbniss.

Bei ST macht der Makefile Generator so etwas:

..makefile objects.list $(OPTIONAL_TOOL_DEPS)
arm-none-eabi-gcc -o "Ux_Device_HID_CDC_ACM.elf" @"objects.list"...

Das funktioniert, aber wie generiert man diese Datei: objects.list
Da stehen alle Objektpfade für den Linker drin.

IDE ist Eclipse und es wird die Toolchain 
"gcc-arm-none-eabi-10.3-2021.10" benutzt. In Eclipse ist das generieren 
automatischer Makefiles aktiv.
Sonst muss ja für jeden dieser 1000 unterordner alles per Hand in ein 
Makefile bauen.

[foobar (Gast)]

See:
  https://www.gnu.org/software/make/manual/html_node/File-Function.html

[J. S. (jojos)]

das Problem ist das der makefile Generator im CDT da nicht 
konfigurierbar ist. Da habe ich auch lange gesucht weil Mbed das 32 k 
Zeichen Limit der Kommandozeile auch schon früh gesprengt hat. Ich 
vermute da hilft nur etwas externes mit z.B. cmake zu bauen.

[foobar (Gast)]

Letzte Antwort in:
  https://stackoverflow.com/questions/42841335/eclipse-cdt-how-to-use-an-argfile-for-the-linker-for-a-too-long-command-line

hat eine Lösung - vom Prinzip her: die Linker-Commandline durch "$(file 
>olist,...) linker @olist" ersetzen.

[Sebastian___ (Gast)]

Wie generiert denn ST bei der cubeIDE diese Objeckt Datei? Ich finde 
einfach gar keine Einstellungen. Da geht es ja auch.

[foobar (Gast)]

Ich hab keinen blassen Schimmer von diesen IDEs ...

[Sebastian___ (Gast)]

So geht es:
Command Line Pattern bei den Linker einstellungen.

@$(file >linkcl.rsp,$(subst \,/,${FLAGS}) ${cross_toolchain_flags} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}) ${COMMAND} @"linkcl.rsp"

Danke für die Hilfe.

[W.S. (Gast)]

Sebastian___ schrieb:
> Irgendwann ist jetzt durch die vielen Files im Linker der Puffer im
> Windows übergelaufen.

Ich schätze eher, daß du die maximale Länge für eine Kommandozeile 
überschritten hast. Sowas ist kein Fehler im OS, sondern einfach nur 
eine Gedankenlosigkeit von irgendwem, der da meint, Kommandozeilen 
könnten unendlich lang sein. Abhilfe gibt es seit Ewigkeiten, auch beim 
GCC. Nennt sich Kommandozeilen-Erweiterung. Da steht in der 
Kommandozeile nur der Verweis auf eine Datei, die die ganzen Argumente 
enthält. Und diese Datei kann bei Bedarf richtig lang werden.
Aufrufe:
ARM-NONE-EABI-GCC @compile_gcc.xcl -o setup.thumb.o setup.c
...
ARM-NONE-EABI-LD @link_gcc.xcl

Und die Erweiterung 'compile_gcc.xcl'
-mcpu=arm7tdmi-s
-Wall
-mthumb-interwork
-msoft-float
-DGCC
-ggdb
-IE:/yagarto/include -I.
-mthumb
-O2
-c

Und zum Linken 'link_gcc.xcl'
-Ttext 0x80000000
-Tdata 0x4000C000
-Map linkedgcc.txt
-eHard_Reset
-LE:/yagarto/lib/gcc/arm-none-eabi/4.7.2
-LE:/yagarto/arm-none-eabi/lib
-o linkedgcc.elf
Startup_LPC2220gcc.o
interrupts.o
main.thumb.o
systemtick.thumb.o
setup.thumb.o
...
--start-group -lgcc -lc -lm --end-group


Das war ein mittlerweile 10 Jahre alter Auszug aus der damaligen 
Lernbetty. Aber das Verfahren ist heutzutage noch genauso. Sollte 
eigentlich bekannt sein.

W.S.

[Johann L. (gjlayde)]

> Das Problem ist $(OBJS) $(USER_OBJS) $(LIBS). Das wird bei vielen Files
> so lang das Windows streikt.

Das kann passieren, wenn man viele Object-Files hat und die 
Kommandozeile zu lange wird, etwa wenn lange Pfadnamen verwendet werden.

Eine Lösung ist, die Dateinamen in eine Textdatei <name> zu schreiben 
und diese als @<name> zu übergeben.

gcc ist allerdings nur ein Treiber-Programm, und stellt auch selber 
Kommandozeilen-Aufrufe zusammen und führt diese aus.  Wenn man also 
@<name> mit vielen C-Dateien hat, der Treiber @<name> auspackt und die 
Objects an den Linker weiterreicht, kann es sein, dass die Kommandline 
zu lange wird.

Ähnliches kann passieren, wenn man linken will und der Compilertreiber 
Tools wie ld, collect2 oder (per Linker-Plugin) lto1 aufruft.

Der Treiber (in deinem Falle also arm-none-eabi-gcc, was kein Compiler 
ist. Compiler ist cc1, cc1plus oder lto1) kann auch selbst @-Files 
erstellen, allerdings macht er das nur dann, wenn GNU ld als Linker 
verwendet wird und GCC dies beim Configure festgestellt hat.  Dieser 
Schritt funktioniert bei Cross-Compilern nicht immer problemlos, bzw. 
configure kann die Tools nicht ausführen, weil für einen anderen Host 
(bei Canadian-Cross Konfiguration) generiert wird.

Falls dies der Fall ist, kann man beim configure --with-gnu-ld angeben, 
so dass das Treiberprogramm @-Dateien selbst erstellt.

[DerEinzigeBernd (Gast)]

Johann L. schrieb:
> Das kann passieren, wenn man viele Object-Files hat und die
> Kommandozeile zu lange wird, etwa wenn lange Pfadnamen verwendet werden.

Wenn die Object-Files nicht kreuz und quer in der Gegend verstreut 
herumliegen, kann man die Pfade auch komplett weglassen, wenn vor dem 
Linkeraufruf in das Verzeichnis mit den Object-Files gewechselt wird.

Dann genügen die Dateinamen.

[Johann L. (gjlayde)]

Schon mal schwer umzusetzen wenn IDE verwendet wird wie hier.

Außerdem müssen dann alle Objecs im gleichen Verzeichnis liegen, oder 
man muss erst aufwändig die relativen Pfade bestimmen (oder die 
absoluten verwenden, was dann nur für einen Teil der o's was einspart).

Ist aber ein bekanntes Problem unter DOS-igen OSen.