Forum: Compiler & IDEs wie aktiviere ich ASM-Ausgabe in STM32CubeIDE?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Gunnar F. (gufi36)


Lesenswert?

Hallo zusammen, ich kriege das nicht hin!
Ich finde durchaus die Compiler-Flags, die dafür gebraucht werden:
(Stackoverflow Zitat: Use the -S option to gcc (or g++), optionally with 
-fverbose-asm which works well at the default -O0 to attach C names to 
asm operands as comments.)
Aber nicht, wo in der IDE ich sie eingebe. Ich kenne das Listfile, da 
finde ich aber (in den 18.000 Zeilen) nicht meinen eigenen Code. Sieht 
alles aus wie HAL-Funktionen. Aus anderen IDE kenne ich eine 
synchronisierte View, die die gerade aktive Quellcodezeile in ASM zeigt. 
Aber wenn nur meine Symbole im ASM enthalten wären, ging es ja schon. 
STRG+F findet aber keine einzige. Ich nutze hier die CubeIDE 1.7.0, ist 
aber bei 1.13.0 auch nicht anders. Dazu standard GCC, alle Settings so 
wie von STM vorgegeben.
Ich habe mir eine neue BuildConfig erzeugt (ASM-List) und dort probiert, 
die Flags unter ToolSettings/MCU GCC Compiler/Miscellaneous/Other Flags 
hinzuzufügen. Mit oder ohne führendes '-', resultiert immer nur mit 
Compilerfehler "Syntax Error". In den Post Build Steps war ich nicht 
erfolgreicher.
Freue mich, wenn mir da jemand den Weg aufzeigt! Danke!

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Code schlägt Prosa.

Davon ab: -S erzeugt zwar eine Assemblerdatei, passt aber schlecht in 
die meisten Build-Umgebungen / Makefiles die -c erwarten und eine .o 
erzeugen.  Mit -S bekommt man dann Assembler Code in der .o.

Besser geht zusätzlich -save-temps was auch mit -c funktioniert, und 
auch ohne -c, -S und -E.

Den Dateinamen, unter dem das Assembly gespeichert wird kann man mit 
-save-temps=obj oder -dumpbase "string" weiter anpassen.

von Gunnar F. (gufi36)


Lesenswert?

Leider verstehe ich Deine Antwort nicht. Wo und wie muß ich diese Flags 
in CubeIDE eintragen?

von Fabian S. (fsasm)


Lesenswert?

Du willst also so was wie https://godbolt.org/ aber nur halt in der IDE. 
Hatte ich mal vor Jahren in Attolic IDE (?) und es wurden zu jeder 
Funktion auch Größe des Programmcodes und Stackframes angezeigt. Das hat 
man nicht über die Build config eingestellt, sondern als Plugin 
eingebunden. Keine Ahnung wie man das mit STM32CubeIDE macht. Aber ja, 
all diese Informationen kann der GCC ausgeben bzw. die build tools 
können es extrahieren.

von Gunnar F. (gufi36)


Lesenswert?

Fabian S. schrieb:
> Hatte ich mal vor Jahren in Attolic IDE (?)

Stimmt, die war es. Hatte ich inzwischen selbst nicht mehr gewusst...
Ganz früher hatte ich die MCU8051IDE verwendet und da war das auch sehr 
schön integriert. Aber auch ohne synchrones Scrollen wäre es schon gut, 
wenn C-Code und ASM "interleaved" dargestellt würden.

: Bearbeitet durch User
von Mike R. (thesealion)


Angehängte Dateien:

Lesenswert?

Ich weiß gerade nicht, was du genau vorhast, aber wenn du einen 
zusätzlichen Parameter an den Compiler übergeben willst sollte das hier 
gehen:

Rechtsklick auf das Project -> Properties -> siehe Bild

von Gunnar F. (gufi36)


Lesenswert?

Mike R. schrieb:
> Ich weiß gerade nicht, was du genau vorhast, aber wenn du einen
> zusätzlichen Parameter an den Compiler übergeben willst sollte das hier
> gehen:
> Rechtsklick auf das Project -> Properties -> siehe Bild

Ja danke, aber genau das habe ich ja probiert:

Gunnar F. schrieb:
> die Flags unter ToolSettings/MCU GCC Compiler/Miscellaneous/Other Flags
> hinzuzufügen. Mit oder ohne führendes '-', resultiert immer nur mit
> Compilerfehler "Syntax Error"

von Andreas B. (abm)


Lesenswert?

Hm, das geht z. B. via

objdump -S -l -w -d -t -C --visualize-jumps blabla.elf

Aber das ist halt ein extra Aufruf nach Compile und Link, keine Option 
für Compiler bzw. Linker. Geht bei mir ganz zwanglos im Makefile. Jaja, 
das ist nur was für Fossilien wie mich ... Bei Klicki-Bunti???

von Gunnar F. (gufi36)


Lesenswert?

Andreas B. schrieb:
> Jaja, das ist nur was für Fossilien wie mich ... Bei Klicki-Bunti???

Danke Andreas, ich sehe mir das mal an! Fossil bin ich selber, nur der 
Einstieg in die Programmierung ist doch komplex und da war ich froh, 
dass die IDE mir den ganzen Kram mit make und kryptischen Parametern 
erstmal abnimmt.

von Harald K. (kirnbichler)


Lesenswert?

Andreas B. schrieb:
> Hm, das geht z. B. via
>
> objdump -S -l -w -d -t -C --visualize-jumps blabla.elf

Ist das nicht ein nachträgliches Disassemblieren?

Da ist der "echte" Assemblerquelltext mit den jeweiligen C-Sourcezeilen 
als Kommentar doch deutlich wertvoller, oder?

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Gunnar F. schrieb:
> Ich kenne das Listfile, da finde ich aber (in den 18.000 Zeilen) nicht
> meinen eigenen Code. Sieht alles aus wie HAL-Funktionen.

Der ist da aber drin. Kann nur gern mal untergehen zwischen den vielen 
HAL-Funktionen.

-save-temps finde ich nicht so sinnvoll, weil das nur die Ergebnisse der 
einzelnen Compiler Aufrufe zeigt. Der Linker kann da aber schon auch 
noch rein pfuschen.

Ein separater objdump-Aufruf auf das fertige .elf-File ist auch 
sinnvoll, liefert letztlich das gleiche wie o.g. Listfile, aber man kann 
die Kommandozeilenparameter anpassen und sich mehr ausgeben lassen.

Harald K. schrieb:
> Da ist der "echte" Assemblerquelltext mit den jeweiligen C-Sourcezeilen
> als Kommentar doch deutlich wertvoller, oder?

Kommt drauf an...  Die Optimierung würfelt den C-Code derart 
durcheinander, dass der Zusammenhang kaum ersichtlich ist und der C-Code 
dazwischen oft ziemlich deplatziert ist. Dafür finde ich den optimierten 
Assemblercode an sich durchaus lesbar, viel besser als den 
nicht-optimierten.

: Bearbeitet durch User
von Andreas B. (abm)


Lesenswert?

Harald K. schrieb:
>> objdump -S -l -w -d -t -C --visualize-jumps blabla.elf
> Ist das nicht ein nachträgliches Disassemblieren?
> Da ist der "echte" Assemblerquelltext mit den jeweiligen C-Sourcezeilen
> als Kommentar doch deutlich wertvoller, oder?

Jein, natürlich müssen die Sourcen mit "-g" kompiliert werden, dann 
landen in der Elf-Datei gerade auch die Infos, die zum sinnvollen 
Disassemblieren inklusive Source-Code nötig sind. "strings blabla.elf" 
ist schon ganz aufschlußreich ...

Im Übrigen kann der Compiler allein gar nicht ein vollständiges Listing 
erzeugen, denn der sieht ja immer nur je eine Source- und Objekt-Datei. 
Erst der Linker macht daraus das "Komplettpaket", und der kann/wird das 
ganze auch noch kräftig bearbeiten.

von Monk (roehrmond)


Lesenswert?

Gunnar F. schrieb:
> Einstieg in die Programmierung ist doch komplex

Den Einstieg macht man heute nicht mehr mit Assembler. Diese Sprache 
wird nur noch punktuell in sehr speziellen Fällen verwenden.

Wenn du sehen willst, welchen Assembler-Code der Compiler erzeugt, 
benutze die Compiler-Optionen
1
-g -Wa,-adhlns="$(@:%.o=%.lst)"
Du findest dann für jede Quell-Datei eine *.lst Datei im Verzeichnis 
Debug oder Release.

: Bearbeitet durch User
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Btw, falls du es noch nicht gefunden hast:

ARM-ASM-Tutorial

von Rolf M. (rmagnus)


Lesenswert?

Niklas G. schrieb:
> Dafür finde ich den optimierten Assemblercode an sich durchaus lesbar,
> viel besser als den nicht-optimierten.

Der Assembler-Code wird im Assembler nochmal optimiert? Ich dachte, alle 
Optimierungen finden vor der Assemblierung statt.

von Gunnar F. (gufi36)


Lesenswert?

Monk schrieb:
> Gunnar F. schrieb:
>> Einstieg in die Programmierung ist doch komplex
>
> Den Einstieg macht man heute nicht mehr mit Assembler. Diese Sprache
> wird nur noch punktuell in sehr speziellen Fällen verwenden.
>
> Wenn du sehen willst, welchen Assembler-Code der Compiler erzeugt,
> benutze die Compiler-Optionen
>
1
> -g -Wa,-adhlns="$(@:%.o=%.lst)"
2
>
> Du findest dann für jede Quell-Datei eine *.lst Datei im Verzeichnis
> Debug oder Release.

Stefan, ich freue mich ja über Deine Hilfe! Aber den Einstieg in die 
Programmierung in Assembler habe ich seit vielen Jahren hinter mir. Wie 
im Titel beschrieben, nutze ich die CubeIDE und dort code ich natürlich 
in C. Würde mich halt nur interessieren, wie der Compiler bestimmte 
Phrasen übersetzt. Im konkreten Fall war das zum Beispiel
1
if(count%1000 == 0)
Aber2

Gunnar F. schrieb:
> Ich finde durchaus die Compiler-Flags, die dafür gebraucht werden:
> (Stackoverflow Zitat: Use the -S option to gcc (or g++), optionally with
> -fverbose-asm which works well at the default -O0 to attach C names to
> asm operands as comments.)
> Aber nicht, wo in der IDE ich sie eingebe.

Mike R. hat ja sogar freundlicherweise einen Screenshot von der Stelle 
in den Projekteigenschaften gepostet, aber wenn ich sie dort eintrage, 
erhalte ich nur noch einen Syntax Error.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Rolf M. schrieb:
> Der Assembler-Code wird im Assembler nochmal optimiert

Der Assembler-Code, der bei einem optimierenden Compiler-Lauf 
herauskommt.

von Monk (roehrmond)


Angehängte Dateien:

Lesenswert?

Gunnar F. schrieb:
> Mike R. hat ja sogar freundlicherweise einen Screenshot von der Stelle
> in den Projekteigenschaften gepostet, aber wenn ich sie dort eintrage,
> erhalte ich nur noch einen Syntax Error.

Bei mir funktioniert es genau dort mit genau dem String, den ich dir 
nannte.

von Rolf M. (rmagnus)


Lesenswert?

Niklas G. schrieb:
> Rolf M. schrieb:
>> Der Assembler-Code wird im Assembler nochmal optimiert
>
> Der Assembler-Code, der bei einem optimierenden Compiler-Lauf
> herauskommt.

Ok, aber es ging doch um Assember-Code direkt aus dem Compiler vs. 
assemblierter und wieder disassemblierter Code und nicht um optimierten 
vs. unoptimierten Code.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Rolf M. schrieb:
> Der Assembler-Code wird im Assembler nochmal optimiert? Ich dachte, alle
> Optimierungen finden vor der Assemblierung statt.

Zunächst mal gibt es -mrelax, das der Linker macht.  Zur Lesbarkeit hat 
das aber nix zu sagen.

Dann kann der Compiler nochmal nach dem Assembler laufen, etwa bei 
LTO.  In dem Fall enthält das 1te Assembly nicht den finalen Code (oder 
sogar nur Bytecode), ist also nur bedingt zu gebrauchen.

von J. S. (jojos)


Lesenswert?

Man kann auch für einzelne Quelldateien geänderte Optionen angeben, das 
ist ein gutes Feature in der IDE. Dazu dann Properties der jeweiligen 
Datei auswählen.

Wenn das Ursprüngliche Problem aber ist das eigene Symbole nicht zu 
finden sind, dann hat der Compiler/Linker da vielleicht etwas 
wegoptimiert. Z.B. wenn Code in Pfaden steht die nie durchlaufen werden.

von Gunnar F. (gufi36)


Lesenswert?

Monk schrieb:
> Bei mir funktioniert es genau dort mit genau dem String, den ich dir
> nannte.

Danke Dir nochmals! Ich probiere das und jetzt funktioniert es sicher 
auch!

von Gunnar F. (gufi36)


Lesenswert?

Monk schrieb:
> Bei mir funktioniert es genau dort mit genau dem String, den ich dir
> nannte.

Hast Recht, das funktioniert! Offenbar hatte ich nach der Recherche auf 
Stackoverflow einfach falsche Flags gefunden, die mit Syntax Error 
quittiert wurden.
Die Flags, die Du vorgeschlagen hast, finde ich noch nicht mal NACHDEM 
ich in der 1000seitigen Doku von GCC gesucht habe! Aber wie gesagt, ich 
finde das interessant, mal den ASM-Code zu sehen, was der Compiler dann 
aus meinen Machwerken gemacht hat. Ich hatte mich oft erwischt, dass ich 
gleichzeitig versuche zu coden und zu optimieren, mich dabei dann 
gedanklich verrannt habe. Inzwischen lasse ich den Compiler eher seine 
Arbeit machen und vertraue ihm. So kann ich ihm trotzdem mal auf die 
Finger gucken.
(muss nur noch etwas Assembler lernen....)
Nochmal danke für Eure Hilfe!

von Norbert (der_norbert)


Lesenswert?

Gunnar F. schrieb:
> Die Flags, die Du vorgeschlagen hast, finde ich noch nicht mal NACHDEM
> ich in der 1000seitigen Doku von GCC gesucht habe!

Braucht keine 1000 Seiten:
»man objdump«
Da ist alles drin.

von Niklas G. (erlkoenig) Benutzerseite


Angehängte Dateien:

Lesenswert?

Ich mach das immer so:
1
arm-none-eabi-objdump -r -d -C "${ProjName}.elf" > "${ProjName}.S"

als Post-Build-Step eintragen. Vorteil: Es wird garantiert das finale 
Ergebnis geliefert, und nicht das, was erst noch vom Linker verwurstet 
wird. Wenn man den Sourcecode da hinein gemischt habe möchte, fügt man 
noch "-S" hinzu.

von Monk (roehrmond)


Lesenswert?

Irgendwann modifiziert der Prozessor den code nochmal, bevor er 
ausgeführt wird. Dann blickt keiner mehr durch, was da eigentlich unter 
der Haube abläuft.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Monk schrieb:
> Irgendwann modifiziert der Prozessor den code nochmal, bevor er
> ausgeführt wird.

Du meinst Microcode? x86 macht das schon lange, Cortex-M anscheinend 
nicht. Out-of-Order-Execution, superskalere Ausführung, Caches gibt es 
da aber schon, falls man das als "Modifikation" des Codes zählt.

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.