Beej's Quick Guide to GDB (2009)

174 28 8 years ago

kylel• 8 years ago

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

taneq• 8 years ago

This got me started with socket programming back in 2000 or whenever, and I still refer to it occasionally. :D

myrloc• 8 years ago

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• 8 years ago

Recently came across this nice guide on Git pull request workflow: 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.

spicymaki• 8 years ago

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

atso• 8 years ago

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• 8 years ago

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

tomjakubowski2• 8 years ago

Yes. The GNU manuals tend to be excellent sources. GNU Make's is particularly great. https://www.gnu.org/software/make/manual/make.html

AdmiralAsshat• 8 years ago

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

exDM692• 8 years ago

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• 8 years ago

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.

exDM692• 8 years ago

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• 8 years ago

Beej is the man. I liked his networking guide.

davidw• 8 years ago

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

throwaway456321• 8 years ago

Excellent guide, hope this brings it to more people

brendangregg• 8 years ago

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

chris_wot• 8 years ago

Thanks! Great writeup

pixelbeat__• 8 years ago

Very nice guide, debugging a practical example

My own debugging with gdb summary: http://www.pixelbeat.org/programming/debugger/

TheAceOfHearts• 8 years ago

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

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

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

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

userbinator• 8 years ago

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• 8 years ago

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.

danellis• 8 years ago

How is CLion for embedded work these days? If I have, say, an ARM GDB server running, can I use that with CLion's debugger?

davidrm• 8 years ago

Kind of. After connecting to the gdb server, CLion's GDB client usually sends some commands (IIRC start) that will not return a proper response because the server does not support it. Our solution was writing a wrapper to the GDB's machine interface that just ate the problematic commands that are being sent and from then on it works. I don't know if it has been fixed, this is the most recent article i found and it's been a while since I last tried to tackle this problem (previous job).

https://blog.jetbrains.com/clion/2017/12/clion-for-embedded-...

tomjakubowski2• 8 years ago

gdb has been scriptable with python since 7.0 https://sourceware.org/gdb/onlinedocs/gdb/Python.html#Python

tptacek• 8 years ago

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.

toomanybeersies• 8 years ago

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.

rdtsc• 8 years ago

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.

Beej's Quick Guide to GDB (2009)

Related Stories