ARM .o liste erstellen.

Gast #7328692
Lesenswert?

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.

1
USBX_pcdc_ra6e1.elf: $(OBJS) $(USER_OBJS) $(LINKER_SCRIPT) makefile $(OPTIONAL_TOOL_DEPS)
2
  @echo 'Building target: $@'
3
  @echo 'Invoking: GNU ARM Cross C Linker'
4
  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
5
  @echo 'Finished building target: $@'
6
  @echo ' '

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

1
make (e=87): Falscher Parameter.

ist das Ergbniss.

Bei ST macht der Makefile Generator so etwas:

1
..makefile objects.list $(OPTIONAL_TOOL_DEPS)
2
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.

#7328730
Lesenswert?

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.

Gast #7328803
Lesenswert?

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

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

Danke für die Hilfe.

Gast #7329645
Lesenswert?

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.

Beitrag #7329699 wurde von einem Moderator gelöscht.
Persönliche Seite #7329715
Lesenswert?

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.

Gast #7330149
Lesenswert?

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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren