That's a good summary. Anything from Beej is very good usually.
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.
Remote debugging and especially the extended-remote mode are worth knowing.
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.
As someone who's spent a good amount of time in both GDB and Visual Studio don't be so quick to knock the dev tools on Windows, they're really quite good.
Windows is a platform I very seldom use. I had a few hour debugging job, so not worth installing the dev tools. I could just use the tools I always do.
Conditional breakpoints would be a good GDB skill to cover as well (e.g. b foo if(bar==5) ). Particularly because I usually forget how to do it properly when checking string values with memcmp and have to google around for a few minutes...
The only thing I'd add to this is "commands", which executes a series of GDB commands when a breakpoint gets hit, and has been supremely useful for me for all sorts of debugging tasks.
The manual is worth a read. This is a software (as gcc) in which the "man" page or the information displayed with "--help" is not near the bunch of things there are described in the complete documentation.
This guide was a lifesaver when I had to learn how to use GDB on the fly for my 4th year embedded systems paper back at university.
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.
Readit News
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.