Beej's Quick Guide to GDB (2009)
beej.us
beej.us
My own debugging with gdb summary: http://www.pixelbeat.org/programming/debugger/
Watches are incredibly useful. I remember struggling with a bug, wasted days or even weeks on it. Then during lunch an older more experience engineer told me to use watchpoints, and just like that I could see the trace of what was writing over that particular memory address and the problem was solved. It's like in the movies where the master utters some cryptic koan and the struggling apprentice is suddenly enlightened.
Speaking of corrupted memory, another command to add is "x" it stands for "examine memory" and it does just that. Then after examining the memory, for fun, set a watchpoint to see what code ends writing or reading from it.
That is usually my default workflow. The debugger (client and frontend) run on my desktop box while the app is running under gdbserver on an ARM board on the network.
The other day I was debugging a Windows game on my Linux laptop, editing in vim, compiling with x86_64-w64-mingw-clang and gdbserver running on my desktop PC. Not the most comfortable development environment but sure as hell beats learning another debugger and installing dev tools on Windows.
His networking and IPC guides are also one of the sole reasons I managed to pass my 3rd year operating systems paper. From memory we were actually recommended to use his networking guide instead of any particular textbook.
All the important stuff is in the first 4 pages. I have the PDF version on my desktop. Also printed pages 3 and 4 and stuck it to my cubicle wall.
I'd suggest trying out lldb [0] as an alternative to gdb. In general it has more sensible commands [1] and it can be scripted with python.
If you're willing to pay, CLion [2] is amazing and it includes an interactive debugger [3] which, IMO, completely blows away these CLI tools.
[0] https://lldb.llvm.org/index.html
[1] https://lldb.llvm.org/lldb-gdb.html
I completely disagree (and I don't think GDB's command set is all that great either); the page you linked shows that LLDB's commands are even longer, which is extremely annoying when you're forced to use it for any length of time. Getting a good standard hexdump out of either is a pain too, and LLDB has this ridiculously stupid arbitrary limit of 1024 bytes to display each command (which can be overridden by specifying an additional option each time, but... why!?)
I think "more sensible commands" would be what WinDbg and SoftICE have. Short and unobtrusive.
Where? In almost all cases, LLDB has an alias for the GDB command.
https://blog.jetbrains.com/clion/2017/12/clion-for-embedded-...