Finde Ursache für STM32 Linker Wanung nicht!

[Dirk (Gast)]

Hallo.

Ich habe ein älteres Projekt bei dem ich eine ferige LIB einbauen muss.
Leider haben ich das ganze nur als LIB.

1. Problem:
Nun bekomme ich aber eine Wanung wo ich die ursache nicht finde.

Hier mal die Meldungen in gekürzter Fassung:

/emblocks/gcc/4.7.3/ld.exe: warning: src\lib_m4.a(bsac.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail

||warning: src\lib_m4.a(bsac.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail|

Ich finde nur nirgends wchar_t.  Wo ist das?
Und wieso ist das mal als 2 und mal als 4 Byte angegeben, wie kommt man 
drauf das auf 2 zu ändern?
Oder warum ist das bei mir auf 4?


2. Problem mit der LIB:
Die LIB benutzt die FPU (softcalling (softfp)) ich hatte dagegen (hard) 
eingestellt. Na gut das kann man ja umstellen und sollte ncith weiter 
stören.
Aber ist bei der verwendung von FREERTOS dabei noch was zubeachten?
Es läuft alles aus der LIB in einem Task und kein anderer verwendet die 
FPU.

VG Dirk

[Oliver S. (oliverso)]

Dirk schrieb:
> Ich finde nur nirgends wchar_t.  Wo ist das?

Ist für dein Problem eigentlich egal

Dirk schrieb:
> warum

https://stackoverflow.com/questions/19489354/how-to-set-2-byte-wchar-t-output/23896853

Frag den, der die lib gebaut hat.

Oliver

[Rolf M. (rmagnus)]

Dirk schrieb:
> Ich finde nur nirgends wchar_t.  Wo ist das?

Kommt auf die Sprache an. In C ist das in stddef.h definiert, in C++ ist 
es im Sprachkern eingebaut.

> Und wieso ist das mal als 2 und mal als 4 Byte angegeben, wie kommt man
> drauf das auf 2 zu ändern?
> Oder warum ist das bei mir auf 4?

Wie groß wchar_t ist, ist compilerspezifisch.

[Dirk (Gast)]

Ich bin schon froh das ich die LIB habe, den wirklichen Hersteller kenne 
ich nicht.
Die kommt zwar aus Rechtlicht sauberen Quellen, NDA & Co musste gemacht 
werden, aber eine vernünnftige Doku kann ich lange suchen.

Die Erklärung bei stackoverflow ist schon recht hilfreich.
Muss jetzt nur sehen ob ein umstellen auf 2 Byte meinen Code 
beeinflusst.


Hat jemand auch noch eine Meinug zu meinen 2. Probem / Frage.

VG Dirk

[Klaus W. (mfgkw)]

Ich glaube, bei FreeRTOS muß bei einer echten FPU bei einem Taskwechsel 
mehr auf dem Stack gerettet werden (eben die ganzen FPU-Register).

Deshalb wirst du (wenn du eh keine FPU nutzt) besser mit Soft-FPU 
fahren.

Bin aber ehrlich gesagt nicht sicher, ob es wirklich einen Unterschied 
macht.

[Dirk (Gast)]

Die LIB nutzt die FPU nur mein Code bis jetzt nicht!

[Klaus W. (mfgkw)]

Vergiß meinen Text wieder.
Wenn die Lib intern die FPU nutzt, kann sie darin ja unterbrochen 
werden, es muß also ohnehin das volle Sortiment bei einem Kontextwechsel 
gerettet werden.
Daß nur die eine Task die FPU nutzt, kannst du meines Wissens nirgends 
sagen - es wird trotzdem so ablaufen, als ob jede Task es könnte.

softfp heißt ja, daß erstens die FPU genutzt werden kann, und zweitens 
aber Funktionsaufrufe nicht über FPU-Register gehen, sondern wie ohne 
FPU.

Wenn du deinen Code kompilierst mit softfpu, kann es trotzdem passieren, 
daß FPU-Code generiert wird (z.B. um Register zu nutzen und die 
nicht-FPU-Register zu sparen).
Falls du das vermeiden möchtest (wozu ich keinen Grund sehe), könntest 
du auch mit -mfloat-abi=soft kompilieren. Das sollte zu der Lib passen.
Ohne RTOS wäre vermutlich softfp schneller als soft, zumindest nicht 
langsamer.
Mit RTOS mag es anders sein. Müsste man testen.

[Dirk (Gast)]

Beim Task Wechsel sollte schon drin sein das die FPU gesichert wird, 
wenn nicht sollte das kein Problem sein das einzuschalten.
Ich denke da wird es Beispiele geben, wenn es noch nicht im code drin 
ist.

Was die Lib intern macht kann ich nicht beeinflussen, softfp aufrufe 
müssten langsamer sein, aber dann doch deutlich schneller als wenn man 
float wirklich in Software macht.

Nachher prüfe ich das mit wchar_t und wenn diese Dumme Meldung weg ist 
kann ich endlich versuchen die LIB zu verwenden.

[Til S. (Firma: SEGGER) (til_s)]

Wie im Prinzip schon gesagt wurde möchte der Linker dir sagen das du 
bitte für die Library und deine Applikation die gleiche Calling 
Convention benutzen sollst.
Es funktioniert halt nicht wenn z.B. deine Applikation meint ein wchar_t 
wäre 4 Bytes groß und ruft eine Library Funktion auf, die aber einen 2 
Byte wchar_t Parameter erwartet.

Beim GCC gibt es für die FPU folgende Settings:
https://wiki.segger.com/GCC_floating-point_options

Auch da müssen Library und Applikation die gleichen Settings benutzen 
damit z.B. Parameter über die richtigen Register übergeben werden (FPU 
Register bei hard und CPU Register bei soft und softfp). soft und softfp 
können gemixt werden.

Dirk schrieb:
> Beim Task Wechsel sollte schon drin sein das die FPU gesichert wird,
> wenn nicht sollte das kein Problem sein das einzuschalten.
> Ich denke da wird es Beispiele geben, wenn es noch nicht im code drin
> ist.
Die meisten RTOS sollten heutzutage das Arm Cortex-M4F Lazy Stacking 
Feature benutzen (embOS macht das so und FreeRTOS wahrscheinlich auch). 
Damit werden FPU Register beim Context Switch automatisch 
gesichert/restauriert und als Anwender brauche ich mir keine Gedanken 
darum machen. Evtl. muss man bei FreeRTOS ein Define setzen, um das 
einzuschalten. Sag Bescheid, falls du da Hilfe brauchst.

[Dirk (Gast)]

So einige Tage später!

Wenn man wchar_t beim Compilieren auf 2 Byte dreht ist zwar mein C-Code 
wunder schön so gemacht aber die GCC Libs halt nioht und das ergibt dann 
mal so richtig viele Warnungen.

Habe beim Lieferanten nach gefragt was das soll und als Antwort bekommen 
das das wohl zur Zeit der Erstellung stand der Technik war.
Hä? Mein GCC ist gut 2 Jahre vor der Lib entstanden und ich denke das 
auch heute kaum eine GCC LIB für den STM32 auf 2 Byte ausgelegt ist.

Vielleicht kannt ja jemand für den Liker noch so einen Trick damit die 
GCC LIBs mit 2 Byte arbeiten und ich die Warnungen los werde.


FREERTOS sichert bei mir die FPU, also keine Probleme zu erwarten.

[Oliver S. (oliverso)]

Dirk schrieb:
> Vielleicht kannt ja jemand für den Liker noch so einen Trick damit die
> GCC LIBs mit 2 Byte arbeiten und ich die Warnungen los werde.

Steht doch alles im o.a. stackoverflow-Beitrag. Von Warnung einfach 
unterdrücken bis gcc-toolchain neu bauen. Was du davon brauchst, musst 
du selber wissen.

Eine zusätzliche Möglichkeit wäre, die fragwürdige lib nach /dev/null zu 
schieben, und einfach eine selber zu programmieren, bzw. eine andere zu 
suchen.

Oliver