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!
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.
Leider verstehe ich Deine Antwort nicht. Wo und wie muß ich diese Flags in CubeIDE eintragen?
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.
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
Angehängte Dateien:
-
CubeIDE.JPG
50 KB
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
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"
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???
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.
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?
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
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.
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
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.
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.
Rolf M. schrieb: > Der Assembler-Code wird im Assembler nochmal optimiert Der Assembler-Code, der bei einem optimierenden Compiler-Lauf herauskommt.
Angehängte Dateien:
-
2024-06-23_13-30.png
210 KB
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.
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.
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.
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.
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!
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!
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.
Angehängte Dateien:
-
objdump.png
48 KB
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.
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.
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.