Do you debug with GDB?
Hello,
I am writing a GDB stub for a DSP chip. What I would like to hear from you is what kind of commands do you use and how do you debug.
I need this as a reference for implementing features for me and my coworkers
For example, lets say you encountered an exception at some point of execution. How would you debug it using GDB.
PS: I assume everybody uses things like break, jump, continue and read of registers/variables.
This is interesting last night I wrote a list for myself and now you've asked this question
So it's destined that it has to be shared with youHere's a list of useful commands I think you will probably need to use:
(Don't forget to compile in a way that is proper for GDB (compilation should include symbols GDB needs), it could be done with simply the -g flag, e.g gcc -g prog.c -o prog)
Hope that helps.Code:gdb ./prog (notice executable file is used) break main (or b main) (add a break point to the main function) run (run the program) next (or n) (run the next line) <enter> (repeats last command, whatever it's been) list (or l) (see where you are in the source code) print <var_name> (or p <var_name>) break prog.c:<line_number> (notice source file is used. e.g.: b prog.c:142) continue (run until next breakpoint) until <line_number> step ("next" runs "lines" so skips going into function calls, but that's not always our intended behavior, using "step" you can step inside your function calls) print *<array_name>@<array_length> (e.g.: p *myArr@10) r (re-run the debugging from beginning) quit (or q) kill (kill the program being debugged without quitting gdb) make (running make from inside gdb, IT'S POSSIBLE!) print x = 1 (adds this to the source code of your program!! So if you "make" it'll be changed as you need without leaving the GDB!) info locals (very helpful command shows information of all variables in the current local scope) disable (remove debugging symbols from the executable, usually done when you're finished debugging and everything's fine)
Last edited by narniat; 12-15-2018 at 07:22 PM.
A better flag for gdb is -ggdb (although maybe -g defaults to that?).
And you're missing the all important "bt" (backtrace) command and the "up" and "down" commands for moving up and down the stack frame.
Are you porting gdbserver?
gdbserver - Wikipedia
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
@narniat: thanks good list. However this is not exactly what I wanted to get. I am more interested in approaches. For example lets say you encountered a problem, you ran GDB to debug it and now - do you modify memory, and re execute the program by putting a breakpoint once again on top of the function and jumping there?
@Salem, no do have python server for that. I just write parser for incoming GDB commands (packets) and executive functons if you will to make use of this commands from GDB.
Who said anything about Python?
Gdbserver is a stub you run on target.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
I would love to debug with it. Sadly, it lacks a fundamental feature that I absolutely need -a crutch if you will- automatic display of local variables' content when stepping. This with a console based GUI mode would be priceless.
Atm, there is the -tui flag, which enables a nice console based GUI, but sadly lacks the above mentioned feature. Because of this, I am forced to use LLDB, which comes preinstalled on the macs at my school and has a very very good console GUI mode with hotkeys, source view and stack frame and local variables display.
So you've read this then?
Remote debugging with LLDB
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
