arm gdb layout

[Christoph K. (chriskuku)]

Ich suche eine Quelle, die mir einen Tip gibt, wie ich ein gdb 
Fenster-Layout gestalten kann. Die gnu.gdb newsgroup hatte den letzten 
Beitrag in 2014. Die Sourceware.org-Seite mit gdb-Commands und speziell 
zu TUI paßt offenbar nicht zum arm-none-eabi-gdb. TUI help zeigt auch 
nicht sehr viel.

Die ARM developer community ist auch nicht sehr bevölkert.
Ich kriege ein halbwegs passables layout hin (s. Bild), aber mehr wäre 
schöner.

Ich hätte gerne Adressen, instruction code, instructions und source 
lines im src layout.

Aber help tui sieht sehr "arm" aus (sic!) :)

Weiß jemand, wie man sich ein schönes layout für assembler code bastelt 
? - ich weiß, die meisten machen hier ja C++ :)

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Für was braucht man das?

Als Otto-Normalo verwendet man für einen (z.B.) STM32 eine 
"STM32CubeIDE" und da ist das Debuggen mit drin. Incl 
Quellcode-Debugging.

Weil offenbar die Entwikler dieser SW das auch eingesehen hatten dass 
dies nicht wirklich jemand braucht gab es seit 2014 nichts neues mehr...

[Christoph K. (chriskuku)]

Markus M. schrieb:
> Für was braucht man das?
>
> Als Otto-Normalo verwendet man für einen (z.B.) STM32 eine
> "STM32CubeIDE" und da ist das Debuggen mit drin. Incl
> Quellcode-Debugging.
>
> Weil offenbar die Entwikler dieser SW das auch eingesehen hatten dass
> dies nicht wirklich jemand braucht gab es seit 2014 nichts neues mehr...

Kann auch heißen, daß die Software ausgereift ist und nicht mehr viel 
dran zu tun ist. Es gibt Leute, die gdb heutzutage sehr erfolgreich 
einsetzen. arm-embedded-gdb, openOCD usw. Wenn ich einen Nagel 
einschlagen will, brauche ich einen Hammer. Ich kann natürlich auch 
einen Elektrotacker mit Nagelmagazin benutzen. Habe auch neulich 
festgestellt, daß in der Clisp user Liste ca. 10 Jahre nicht viel 
passiert ist. Trotzdem kann Clisp in vielen Einsatzgebieten nützlich 
sein

Weihnachten ein schönes Erlebnis gehabt: Zum ersten mal mußte ich beim 
Inbetriebnehmen eines Leuchtmittels (Philips HUE LED) ein Handbuch 
lesen.

Und im übrigen bin ich nicht "Otto Normalo".

Sag' mir übrigens mal, wie Du im STM32CubeIDE ein Assembler-Projekt 
kreierst und debuggst, das aus einigen zig .S Modulen besteht, die alle 
in ein .S File inkludiert sind.

Kann das IDE da durch die SRC steppen und auch in die inkludierten SRC 
Files?

gdb kann das.

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Meine letzten Assembler-Dinge sind ca. 15 Jahre her.
Assembler ist mir nicht portabel genug, falls ich Code zwischen einen 
ARM <> PIC <> Java <> irgendwas anderes austauschen muss.
Auch die Startup-Files von einem STM32 brauchen nicht in Assembler 
geschrieben sein, das geht viel übersichtlicher mit C.
Spezial-ARM-Befehle sind in der CMSIS gekapselt, die man somit ebenfalls 
gut nutzen kann.

Daher, für mich ist Assembler unwichtig.

Christoph K. schrieb:
> Kann das IDE da durch die SRC steppen und auch in die inkludierten SRC
> Files?

Ja. Man muss während dem Debuggen die "Disassembler" View auf machen, 
dann kann man den "Opcode" einblenden und darin in jeder Assembler Zeile 
ein Breakpoint setzen.
Siehe "Bild1".

Das sollte auch bei den .s Dateien gehen. (Ich habe gerade keine zur 
Hand...)

[pegel (Gast)]

Christoph K. schrieb:
> Sag' mir übrigens mal, wie Du im STM32CubeIDE ein Assembler-Projekt
> kreierst und debuggst,

Hat mich auch mal interessiert.

Ja, STM32CubeIDE ist es erstmal egal ob es eine main.c oder eine .s 
Datei als Start hat.

Im Bild debugt er artig durch die add.s.
Eine main.c gibt es nicht im Projekt.

[pegel (Gast)]

Du musst bei Bedarf natürlich alle .c Dateien durch deine eigenen .s 
Dateien ersetzen, bzw. alles "unnötige" entfernen.

[Christoph K. (chriskuku)]

Assembler mag für viele heute unwichtig sein, wenn man eine Hochsprache 
(C, C++) benutzt. Meine (FORTH) Kernsoftware ist aber in Assembler 
geschrieben und deswegen ist Assembler geradezu ein Muß.

[aIX4 (Gast)]

Markus M. schrieb:

> Assembler ist mir nicht portabel genug, falls ich Code zwischen einen
> ARM <> PIC <> Java <> irgendwas anderes austauschen muss.

Irgendwie passt das nicht zusammen, oder Du programmierst überall in 
Java .

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

aIX4 schrieb:
> Irgendwie passt das nicht zusammen, oder Du programmierst überall in
> Java .

Java - nein ich bin kein Java Freund. Hab leider hin und wieder ein 
Projekt auf dem Tisch und da muss ich dann C-Funktion in Java übersetzen 
- bei Assembler wäre ich komplett aufgeschmissen, für C gibt es das:
https://www.mtsystems.com/