Hallo, ich würde gerne wissen, ob jemand hier eine gute Anleitung für den Umgang mit dem Debugger gdb kennt, vor allem in Hinsicht auf STM32. Am Besten so einfach wie möglich, aber dennoch gründlich. Danke!
Einfach googlen und die ersten Links klicken. Lesen musst du schon selber. Probier mal das hier https://www.oreilly.de/german/freebooks/rlinux3ger/ch142.html
Naja, ich habe auf irgendwelche besonders guten Empfehlungen gehofft. Aber inzwischen bin ich auch schon zumindest ein bisschen weiter. Ich habe jetzt einen Symbol Table aus einer Executable geladen, die mit -g3 kompiliert wurde. Allerdings finde ich absolut nichts dazu, wie ich nun die Register auslesen kann, wie z.B. RCC_APB1RSTR oder GPIOA_CRL oder so. Mit "p /x GPIOA_CRL" bekomme ich immer nur "No symbol "GPIOA_CRL" in current context. Wieso und wie kann ich das lösen?
> No symbol "GPIOA_CRL"
Vielleicht weil GPIOA_CRL kein Symbol ist sondern ein Makro?
Johann L. schrieb: >> No symbol "GPIOA_CRL" > > Vielleicht weil GPIOA_CRL kein Symbol ist sondern ein Makro? Mit Symbol sind aber ja eigentlich quasi die Bezeichner von Variablen gemeint, oder nicht? Weil mit GPIOA->CRL passiert genau das gleiche. Und hier ist es ein Bezeichner.
Oh, eine Drääääne schrieb: > Mit Symbol sind aber ja eigentlich quasi die Bezeichner von Variablen > gemeint, oder nicht? Ein Makro wird, im Gegensatz zu Variablen oder Konstanten, schon vom Präprozessor ersetzt. Der Compiler sieht den Namen GPIOA nie und kann also auch keine Debug-Informationen dafür erstellen.
Oh, eine Drääääne schrieb: > ich habe auf irgendwelche besonders guten Empfehlungen gehofft. Kann ja keiner wissen, wie weit du da schon bist und was du brauchst. Der Link war eher so zum Einstieg gedacht, mal breakpoints ausprobieren und so. Und bei STM32 bin ich (leider noch) auch schon raus.
Md M. schrieb: > Und bei STM32 bin ich (leider noch) auch schon raus. Ich offensichtlich auch. Aber ich will es zumindest versuchen, weil mich gerade ein Problem dabei ziemlich irre macht und ich den Fehler absolut nicht finde. Alexander F. schrieb: > Oh, eine Drääääne schrieb: >> Mit Symbol sind aber ja eigentlich quasi die Bezeichner von Variablen >> gemeint, oder nicht? > > Ein Makro wird, im Gegensatz zu Variablen oder Konstanten, schon vom > Präprozessor ersetzt. Der Compiler sieht den Namen GPIOA nie und kann > also auch keine Debug-Informationen dafür erstellen. Aber Variablen. Und GPIOA ist eigentlich eine Variable vom Typ GPIO_TypeDef. Das finde ich wie gesagt aber auch nicht. Ich habe auch schon extra eine Variable angelegt, die findet er irgendwie auch nicht. Ich kompiliere mit -g3 und -O0. Dann nutze ich "st-util -p 4500" und "gdb" und im gdb-terminal dann "target remote localhost:4500". Dann mit "file /path/to/executable" die Symbole laden und dann kommt bei "p /x var" wieder die Meldung heraus. Habe ich einen Schritt vergessen?
Oh, eine Drääääne schrieb: > Und GPIOA ist eigentlich eine Variable vom Typ GPIO_TypeDef. Bist du dir da sicher? Ich hab mir jetzt die STM32 Standard Peripheral Library heruntergeladen. Da ist GPIOA ein Makro:
1 | #define GPIOA ((GPIO_TypeDef *) GPIOA_BASE)
|
Alexander F. schrieb: > Oh, eine Drääääne schrieb: > Und GPIOA ist eigentlich eine Variable vom Typ GPIO_TypeDef. > > Bist du dir da sicher? > Ich hab mir jetzt die STM32 Standard Peripheral Library heruntergeladen. > Da ist GPIOA ein Makro:#define GPIOA ((GPIO_TypeDef *) > GPIOA_BASE) Ups. Dazu sage ich jetzt mal lieber nichts mehr...
Alexander F. schrieb: > Ein Makro wird, im Gegensatz zu Variablen oder Konstanten, schon vom > Präprozessor ersetzt. Der Compiler sieht den Namen GPIOA nie und kann > also auch keine Debug-Informationen dafür erstellen. Dann lies dir mal die Dokumentation zu -g3 durch … Der „Präprozessor“ ist halt schon lange kein separater Prozess mehr sondern ein inhärenter Bestandteil des Compilers. Daher ist auch er in der Lage, Debuginformationen an den eigentlichen Compiler durchzureichen. Falls du es nicht glaubst:
1 | j@uriah 1076% cat foo.c |
2 | #define FOO 42 |
3 | |
4 | int main(int argc, char **argv) |
5 | { |
6 | int i = FOO; |
7 | i *= argc; |
8 | return i; |
9 | } |
10 | j@uriah 1077% gcc6 -g3 -o foo foo.c |
11 | j@uriah 1078% gdb801 -q foo |
12 | Reading symbols from foo...done. |
13 | (gdb) b 5 |
14 | Breakpoint 1 at 0x400771: file foo.c, line 5. |
15 | (gdb) r a |
16 | Starting program: /junk/FreeBSD/ports/devel/avr-gcc/foo a |
17 | |
18 | Breakpoint 1, main (argc=2, argv=0x7fffffffe4c0) at foo.c:5 |
19 | 5 int i = FOO; |
20 | (gdb) p FOO |
21 | $1 = 42 |
22 | (gdb) c |
23 | Continuing. |
24 | [Inferior 1 (process 68188) exited with code 0124] |
25 | (gdb) quit |
Jörg W. schrieb: > Dann lies dir mal die Dokumentation zu -g3 durch … Oh, das wusste ich nicht. Zur Vollständigkeit ist hier der Abschnitt zu -g3 aus der gcc Manpage: > Level 3 includes extra information, such as all the macro definitions present > in the program. Some debuggers support macro expansion when you use -g3.
Oh, eine Drääääne schrieb: > Weil mit GPIOA->CRL passiert genau das gleiche. Und hier ist es ein > Bezeichner. Könnte es eventuell sein, dass du einen neueren STM32 nutzt, der gar keine GPIO_CRL und GPIO_CRH hat? So lange mit -g3 kompiliert wird funktioniert bei mir der Zugriff z.B. auf GPIOA->ODR (bei einem Nucleo-F411RE) absolut problemlos mittels
1 | ^C |
2 | Program received signal SIGINT, Interrupt. |
3 | 0x080002d2 in delay (time=time@entry=200) at src/main.c:19 |
4 | 19 for (volatile unsigned j=0; j<20000; j++); |
5 | (gdb) p /x GPIOA->ODR |
6 | $1 = 0x20 |
7 | (gdb) p /t GPIOA->ODR |
8 | $2 = 100000 |
9 | (gdb) |
Oh, eine Drääääne schrieb: > Habe ich einen Schritt vergessen? Vielleicht noch vergessen das Binary zu laden?
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.