Hi,
bis dato habe ich immer blind STM32CubeIDE verwendet, sowohl zum
Programmieren als auch zum kompilieren und flashen. All das geschah
hinter den Kulissen.
Nun habe ich angefangen, mich mit GNU GCC für ARM Architekturen zu
beschäftigen und frage mich, welche Compilerargumente empfehlenswert
sind.
Anbei mein makefile [Kritik und Verbesserungsvorschläge erwünscht]:
-g3: Debugging information
-O0: Debugging produces expected results
ffunction sections / fdata sections: Garbage collection optimization
MMD: ???
MP: ???
MF: ???
MT: ???
Die ersten 3 Kompilerargumente (g3, o0, ffunction/fdata) ergeben Sinn
für mich.
Ich habe allerdings schwer, die ganzen M Argumente zu deuten, wenn ich
sie im GNU GCC Handbuches nachschlage.
Frage 1: Was genau bewirken die?
Frage 2: Ergeben die Sinn?
Frage 3: Würdet Ihr zusätzliche Kompilerargumente empfehlen?
Vielen Dank,
Die -M erzeugen eine Textausgabe, die in ein makefile kopiert werden
kann ("die a.cpp inkludiert x.h" etc. in Makefile-Format).
Brauchst du nur, wenn du die makefile-Regeln nicht ganz von HAnd
schreiben willst.
PS: man kann die auch dazu nutzen, sie mit einem eigenen Target (z.B.
dep) im makefile zu erzeugen und immer im makefile mit include
einzufügen.
Ändert man was an den includes in C, wird mit mit einem make dep alles
wieder korrigiert.
> welche Compilerargumente empfehlenswert sind
Welche Zwiebeln soll ich kaufen?
Normale, Weisse oder Rote? Oder doch besser Knoblauch?
Dein Ansinnen entspringt wohl eher deiner Faulheit.
Aber, sowas wie "empfehlenswert" gibt es nicht.
P.S.
Das was an den Linker gereicht wird, ist noch viel niedlicher.
Alex -. schrieb:> Die ersten 3 Kompilerargumente (g3, o0, ffunction/fdata) ergeben Sinn> für mich.
O0 ergibt allenfalls zum Debuggen einen Sinn, sonst ist O2 die bessere
Wahl. O3 bläht eher den Code auf, bringt aber kaum Performance. Ich
würde außerdem noch vorschlagen:
-Wall -Wextra -Wpedantic -fno-strict-overflow -mslow-flash-data
-mcpu=cortex-m4 -mtune=cortex-m4
Die ersten drei sollten klar sein - schalte Compiler-Warnungen an und
behebe die angemeckerten Stellen, dann brauchst Du nicht soviel zu
debuggen.
No strict overflow: in C ist signed integer overflow nicht definiert,
weil die Negativdarstellung nicht standardisiert ist. Der Compiler darf
solche Stellen einfach wegoptimieren. Das ist heute eher lästig, weil
das Zweierkomplement sich durchgesetzt hat.
Die m-Optionen sind ja selbsterklärend - die erstere berücksichtigt bei
den Optimierungen, daß verteilte Datenzugriffe aufs Flash langsamer sein
können.
Nop schrieb:> No strict overflow: in C ist signed integer overflow nicht definiert,> weil die Negativdarstellung nicht standardisiert ist. Der Compiler darf> solche Stellen einfach wegoptimieren. Das ist heute eher lästig, weil> das Zweierkomplement sich durchgesetzt hat.
Dir ist klar, dass die Option nur die Warnung deaktiviert, nicht das
worüber gewarnt wird?
mh schrieb:> Nop schrieb:>> No strict overflow: in C ist signed integer overflow nicht definiert,>> weil die Negativdarstellung nicht standardisiert ist. Der Compiler darf>> solche Stellen einfach wegoptimieren. Das ist heute eher lästig, weil>> das Zweierkomplement sich durchgesetzt hat.>> Dir ist klar, dass die Option nur die Warnung deaktiviert, nicht das> worüber gewarnt wird?
nehme ich zurück, hab ein W mehr in die Option gepackt. Ist trotzdem
meiner Meinung nach keine gute Idee.
Nop schrieb:> O0 ergibt allenfalls zum Debuggen einen Sinn, sonst ist O2 die bessere> Wahl. O3 bläht eher den Code auf, bringt aber kaum Performance.
... wenn man die Performance braucht. Ich habe das Gefühl, dass für
viele Leute O0 bei 8MHz durchaus schnell genug wäre. Allerdings würde
ich O0 freiwillig nie benutzen. Mit Os wird auch viel effektiverer Code
als mit O0 erzeugt, der Unterschied ist größer als von Os zu O2, aber Os
spart viel Platz. Dadurch wird der Code lesbarer als mit O0, auch wenn
die Zuordnung zum Quelltext nicht mehr ganz so gut ist. Die Verschiebung
beschränkt sich doch auf wenige Zeilen.
Man liest gelegentlich von Fehlern, die je nach Optimierungsstufe
auftauchen oder nicht. Von daher dürfte man keinen Unterschied zwischen
Debug- und Release-Version haben. Auch deswegen ist Os ein guter
Kompromiss, wenn man nicht gerade an Übertakten denkt.
Cartman schrieb:> Aber, sowas wie "empfehlenswert" gibt es nicht.
Nun, -Wall -Wextra sind immer empfehlenswert. Eigentlich sind fast alle
-W Optionen empfehlenswert. Warum sollte man auf die Hilfestellung
verzichten? Es gibt so witzige und trotzdem nützliche wie
-Wmisleading-indentation oder -Wstack-usage=42. Falls man zu einer
Warnung etwas nachlesen möchte hilft -fdiagnostics-show-option.
-std=c2x ist wohl noch zu früh, aber zusammen mit -pedantic würde ich
den Standard festlegen wollen.
-nostdlib würde zum Verzicht auf CubeMX passen;)
-fstrict-volatile-bitfields sollte Default sein, aber sicher ist sicher.
-fno-lto wenn Interrupt-Routinen nicht funktionieren. LTO funktioniert
wohl meistens, aber es ist sehr komplex, also für viele Überraschungen
gut.
-ffunction-sections -fdata-sections -Wl,--gc-sections hab' ich
rausgeworfen, das Manual sagt dazu:
1
Only use these options when there are significant benefits from doing so. ...and you may have problems with debugging if you specify both this option and -g.
Bauform B. schrieb:> Man liest gelegentlich von Fehlern, die je nach Optimierungsstufe> auftauchen oder nicht.
Der Optimierer versteht halt nur C/C++. Wenn man dem was anderes
vorsetzt, braucht man sich nicht zu wundern, daß es nicht funktioniert.
Es spricht überhaupt nichts gegen O2 oder O3, wenn das Profiling ergibt,
daß das Vorteile bringt.
Oliver
Oliver S. schrieb:> Es spricht überhaupt nichts gegen O2 oder O3, wenn das Profiling ergibt,> daß das Vorteile bringt.
Ich hab' nichts gegen O2, wenn das Vorteile bringt. Ich wollte sagen,
dass Feiglinge (Chaoten?) dann auch mit O2 debuggen sollten.
Ich werfe für eine MCU mit single precission FPU noch
-fsingle-precision-constant -Wdouble-promotion
ein. Also Nur Float benutzen und wo double angezogen wird durch Libs
warnen.
Bauform B. schrieb:> Oliver S. schrieb:>> Es spricht überhaupt nichts gegen O2 oder O3, wenn das Profiling ergibt,>> daß das Vorteile bringt.>> Ich hab' nichts gegen O2, wenn das Vorteile bringt. Ich wollte sagen,> dass Feiglinge (Chaoten?) dann auch mit O2 debuggen sollten.
Das sehe ich auch so. Gerade bei eingeschalteten Optimierungen machen
sich viele Programmfehler erst bemerkbar. Wenn man das zum Debuggen
bewusst ausschaltet, muss man nachher noch ein zweites mal debuggen. Und
mit etwas Übung bekommt man ein Programm auch bei -O2 gedebugt.
Nop schrieb:> O0 ergibt allenfalls zum Debuggen einen Sinn, sonst ist O2 die bessere> Wahl.
Auch für das Debugging ist -O0 wenig sinnvoll. Das hat für das Debugging
(und naütrlich die Performance) Nachteile gegenüber -Og. Mir würde kein
Grund einfallen, warum man je -O0 verwenden sollte.
Rolf M. schrieb:> Und> mit etwas Übung bekommt man ein Programm auch bei -O2 gedebugt.
Auch mit -O3. So groß sind die Unterschiede bzgl. Sourcecode-Debugging
da dann auch nicht mehr.
Oliver
Ach Du meine Güte.
Nehmt simplen Assembler und das Thema ist gegessen. Aber warum einfach
wenns auch kompliziert geht? Warum nur Programm programmieren wenn man
nebenbei auch noch die Werkzeuge dazu programmieren kann?
Meine Empfehlung: mindestens die man-page zu cc oder gcc durchlesen, das
ist ein guter Einstieg in grundlegende Zaubereien mit dem Compiler. Am
besten mal ein Wochenende Zeit nehmen und an einem überschaubaren
Projekt alle Optionen durchprobieren:
http://www.nsc.ru/cgi-bin/www/unix_help/unix-man?cc+1
