Arm GCC mit Option -flto erzeugt Fehler

Reiner S. schrieb:
> Wenn ich ohne -flto compeliere läuft es durch.

Dann mach mal ein objdump auf das erstellte ELF und schaue wo malloc 
aufgerufen wird. Vermutlich ist irgendwo in der HAL noch ein printf () 
Aufruf.

soweit ich mich erinnere ist für LTO ein plugin nötig, selbiges teilt 
man ar, ld und co über gcc/g++ mittels

1

-r --plugin /usr/lib/gcc/arm-none-eabi/7.3.1/liblto_plugin.so.0

mit. Pfad je nach Version und Betriebssytem anpassen.

Dr. Sommer schrieb:
> Dann mach mal ein objdump auf das erstellte ELF und schaue wo malloc
> aufgerufen wird. Vermutlich ist irgendwo in der HAL noch ein printf ()
> Aufruf.

Ja malloc wird aufgerufen aber ohne -flto wird des Programm übersetzt 
und USB funktioniert. Ist die Reihenfolge der Module beim übersetzen 
wichtig?

Hallo rµ
Ich arbeite unter Windows und es gib eine liblto.dll. Ich gehe aber 
davon aus das der gcc mit der Option -flto die liblto.dll automatisch 
aufruft.

Bist du sicher, dass das Projekt vollständig neugebaut wurde und keine 
alten Objekt Dateien überlebt haben? -flto erzeugt speziell 
instrumentierte Objektdateien. malloc() in MCU Firmware ist ein bißchen 
wie der Papst auf der Reeperbahn. Sollte man unabhängig davon aus dem 
Projekt eliminieren. Ist dir aber sicher bekannt :)

x^y schrieb:
> Bist du sicher, dass das Projekt vollständig neugebaut wurde und
> keine
> alten Objekt Dateien überlebt haben? -flto erzeugt speziell
> instrumentierte Objektdateien.
Ich denke schon. Habe aber noch mal alle *.o und *.su Dateien gelöscht.
Leider keine Besserung.

> malloc() in MCU Firmware ist ein bißchen
> wie der Papst auf der Reeperbahn. Sollte man unabhängig davon aus dem
> Projekt eliminieren. Ist dir aber sicher bekannt :)
Bei kleinen 8 Bitern ist schon richtig, aber bei einem STM32F407 sehe 
ich kein Problem sich einen Puffer per malloc zu beschaffen.
Außerdem ist das malloc im USB-Treiber von HAL eingebaut.

Habe mir mal die map-Files mit und ohne lto angesehen. Der Fehler mit 
lto
sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'
Im map-File ist _sbrk nicht zu finden.

Beim compelieren ohne lto findet sich _sbrk im map-File

OTG_FS_IRQHandler
                0x08004014       0x10 Src\stm32f4xx_it.o
                0x08004014                OTG_FS_IRQHandler
 .text._sbrk    0x08004024       0x3c Src\syscalls.o
                0x08004024                _sbrk

und das Programm rennt.

MfG

Bindest du das USB-Zeug (also das welches malloc aufruft) über eine 
statische Library ein?

Dann versuch mal per -Wl,--start-group -lblabla -Wl,--end-group zu 
linken.

Eventuell hilft ein

__attribute__((used)) void *dummy(void) {
  return _sbrk(0);
}

irgendwo, um den Compler/Linker zu überzeugen, dass _sbrk tatsächlich 
gebraucht wird und nicht wegoptimiert werden darf. Man könnte das 
__attribute__((used)) auch einfach vor die Definition vom _sbrk setzen, 
aber das wäre mit mehr Aufwand verbunden.

> Bei kleinen 8 Bitern ist schon richtig, aber bei einem STM32F407 sehe
> ich kein Problem sich einen Puffer per malloc zu beschaffen.

Die groesse des Microcontrollers ist vollkommen irrelevant und ausserdem 
auch nur relativ zu deinen Speicheranforderungen.

Du solltest dich aber fragen was macht dein Programm wenn malloc 
zurueckliefert das kein Speicher mehr da ist. Hast du dann eine 
Out-of-Memory BlinkLED? Oder stuerzt dein Programm einmal im Jahr ab?

Olaf

Reine S. schrieb:
> Bei kleinen 8 Bitern ist schon richtig, aber bei einem STM32F407 sehe
> ich kein Problem sich einen Puffer per malloc zu beschaffen

Hoffentlich nicht in einer Interrupt-Routine (lief die ST-USB-Library 
nicht ausschließlich in Interrupts...?). Das gibt sonst lustige Race 
Conditions und Delays.

Ich würde von LTO generell abraten. Das zeug macht nur Probleme. Ich hab 
schon schlechte Erfahrungen damit gemacht, z.B. bei Projekten mit weak 
Symbols und ähnlichem.

Malloc wird nur beim init aufgerufen und sollte somit kein Problem 
seien.
Die anderen Tips werde ich ausprobieren und mich dann melden.

Danke an alle.

Noch mal Danke.
Cube MX generiert ein Modul syscalls.c in der _sbrk definiert ist.
Ich habe wie von Vincent H. vorgeschlagen __attribute__((_used_)) 
eingefügt und das war die Lösung.
Bleibt die Frage warum zur Höllen der GCC _sbrk mit -flto weg optimiert.

MfG
Reiner

Reiner S. schrieb:
> Malloc wird nur beim init aufgerufen und sollte somit kein Problem
> seien.

D.h. die Speicheraufteilung ist gar nicht dynamisch, und du weißt von 
Anfang an wofür wieviel gebraucht  wird? Dann kannst du auch eine 
globale Variable machen. Dadurch sparst du dir den Programmspeicher für 
malloc, und der Linker kann besser den Verbrauch prüfen. Schneller 
starten tut es auch.

Reiner S. schrieb:
> Bleibt die Frage warum zur Höllen der GCC _sbrk mit -flto weg optimiert.

Weil sbrk indirekt über die libc referenziert wird und der Linker das 
nicht auflöst.

Der ganze malloc Kram sitzt in der HAL von STM und das möchte ich nicht 
ändern. Ich denke STM hat sich für malloc entschieden damit es möglichst 
universel ist und mit CubeMX harmoniert. Wider was dazu gelernt mit der 
Libc.
MfG

Le X. schrieb:
> Genau, weil die Anfänger von STM machen ständig nur so Mist, die haben
> ja keine Ahnung.

Was die ST HAL angeht, so ist sie definitiv stinkender Mist. Sie ist 
ganz nett, um eine Übersicht über die notwendigen Register zu kriegen, 
mehr aber nicht.

Die libopencm3 oder direkt Barebone auf die Register ist deutlich 
aufgeräumter.