
Beej's Quick Guide to GDB (2009) - ScottWRobinson
https://beej.us/guide/bggdb/
======
brendangregg
Looks like a great guide. If people are interested in something similar,
here's one I wrote recently [http://www.brendangregg.com/blog/2016-08-09/gdb-
example-ncur...](http://www.brendangregg.com/blog/2016-08-09/gdb-example-
ncurses.html)

~~~
pixelbeat__
Very nice guide, debugging a practical example

My own debugging with gdb summary:
[http://www.pixelbeat.org/programming/debugger/](http://www.pixelbeat.org/programming/debugger/)

------
rdtsc
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.

------
exDM69
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.

~~~
vvanders
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.

~~~
exDM69
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.

------
mesarvagya
Beej is the man. I liked his networking guide.

~~~
davidw
Beej is the man in Bend, Oregon. He regularly hosts hacker nights!

------
AdmiralAsshat
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...

------
tptacek
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.

------
spicymaki
I never knew gdb had a tui mode. It is not even specified in the man page as
an option.

~~~
atso
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.

~~~
jcelerier
(for those who don't know, the full manual can be read with `info gdb` - `man
gdb` is only a short help)

~~~
justin66
People have been ignoring info for almost exactly as long as the FSF has been
trying to supersede man with it.

------
toomanybeersies
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.

------
throwaway456321
Excellent guide, hope this brings it to more people

------
kylel
Beej’s guides are great! He does a fantastic job of describing concepts and
showing implementations. I also recommend his networking guide:
[https://beej.us/guide/bgnet/html/single/bgnet.html](https://beej.us/guide/bgnet/html/single/bgnet.html)

~~~
myrloc
I'm a huge fan of his guides for their readability and straightforward
delivery. I'm always on the lookout for more authors like him - have you come
across any similar authors?

~~~
samoright
Recently came across this nice guide on Git pull request workflow:
[https://github.com/susam/gitpr](https://github.com/susam/gitpr)

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.

------
TheAceOfHearts
I'll preface this by saying that I don't have that much C or C++ experience.
Now on to the topic of debugging em:

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](https://lldb.llvm.org/index.html)

[1] [https://lldb.llvm.org/lldb-gdb.html](https://lldb.llvm.org/lldb-gdb.html)

[2] [https://www.jetbrains.com/clion/](https://www.jetbrains.com/clion/)

[3]
[https://www.youtube.com/watch?v=wUZyoAnPdCY](https://www.youtube.com/watch?v=wUZyoAnPdCY)

~~~
userbinator
_In general it has more sensible commands_

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.

~~~
saagarjha
> the page you linked shows that LLDB's commands are even longer

Where? In almost all cases, LLDB has an alias for the GDB command.

