Hacker News Reader

Comment by dkhenry | Hacker News Reader

GDB skills are one of those super useful abilities that you just can't find in most CS graduates. I often spend a few days with new C developers just teaching them how to use GDB to find problems. They are amazed when they find out you can examine variables and set conditional breakpoints.

View on HN

Just telling them how to start it and use "bt", "up","down","print", and "cont" would be a huge step forward for most developers...

On a related note, it drives me crazy when developers don't know strace/ltrace or the equivalent for their platform. I use strace many times a day to diagnose anything from my own code to figuring out what config files an application actually loads to finding out what's slowing an app down.

strace still blows me away every time I use it. ProcMon on Windows does some of the same stuff, but there's really no comparison.

This is an area where many college professors fall short. In my intro to CS class we learned C, and the professor explicitly told us to debug our code with printf statements. It wasn't until my first job that I even found out about gdb. I can't believe how much time I wasted trying to debug C and C++ code in college with nothing more than printf and cout.

What makes it even worse is the lack of a REPL means that between each change you need to recompile. In any large program this is going to take minutes and they add up. A simple GDB invocation is not only a better way of tracking it down, but can potently save hours.

quick changes that don't require a full recompilation generally mean intermediate files are lying around, which means you only need to recompile changed files and relink. this is usually pretty fast until you start changing headers or something like that. (I'm very used to projects with 30 minute plus full compile times taking less than 10 seconds to recompile and relink single-file changes.)

this is not to say that gdb won't save hilarious amounts of time or that you can be a good C coder without understanding a debugger (I don't think you can), just that the huge compile time thing isn't true most of the time.

Well, ccache helps a lot with that. And sometimes it becomes easier to throw an __asm__("int3"); into your code than try to massage gdb into breaking at the exact right spot in your code and only under certain conditions.

Use of __builtin_trap() (GCC) or raise(SIGTRAP) would be a lot more portable.

gdb being a utility, I believe the student is generally expected to learn it on their own if they like. Much like version control and other things that make the life of a coder easier, but aren't actually part of "Computer Science".

A course learning C is not a course in debugging or learning any particular debugger. When you are just learning the language, printf is probably the best way to do it.

On the other hand, a follow-up course on actual debugging is probably warranted. Debugging might not be part of the Science bit of Computer Science but it is on the practical end of the Computer bit which you'll probably run into doing the Science bit.

Our Computing Systems course had two projects that absolutely required using gdb:

http://courses.cs.vt.edu/~cs3214/fall2011/bomblab/bomblab-cs...

http://courses.cs.vt.edu/~cs3214/fall2011/buflab/buflab-cs32...

Our version of the course was adapted from the CMU course: http://csapp.cs.cmu.edu/ I thought it was an excellent course. It taught students both concepts and skills that I had picked up in a much more ad-hoc manner.

Yes but I don't even remember being told it existed. My intro to C professor made sure we knew that Vi and Emacs existed and gave us enough information to be interested in learning more; why not gdb? My guess is he probably didn't use it.

Yeah we didn't touch any debuggers, I think to an extent they were more just worried about people learning some language basics. The downside of having a first year c/c++ course that didn't just have comp sci students.

The other thing our uni was bad for is that they encouraged us to use vim through the uni servers early on but never have us a proper overview or the resources to really learn it. As a result most saw it as a handicapped text editor that just made things harder.

From the article: "The plan for this section is to write a simple program and then poke it in gdb until arrays start to make sense."

I poked arrays and pointers with printf() for too long before they started to make sense, would have loved an early introduction to debuggers!

Depends on the course and instructors. I wrote this as a TA for our Computing Systems class: http://courses.cs.vt.edu/~cs3214/fall2011/projects/esh3-debu...

When students came to me for help, my first two questions were always "What does gdb say?" and "What does valgrind say?" If they couldn't answer, I'd tell them to go find out.

Yeah, GDB and Valgrind are heavily encouraged at the University of Michigan in both introductory and advanced classes. Talking to friends at other universities, it seems like most other places encourage it too.

As a student attending the University of Michigan this fall, I was looking through the introductory programming course syllabus and it mentions only ddd. Is gdb something used more heavily in further courses more specific to those pursuing a concentration in EECS?

Maybe it's professor specific, but EECS 151, 280 and 281 all stressed using gdb. ddd was mentioned, but most of the debugging examples used gdb. I took these class several years ago though, so it's also possible things have changed since then.

ddd is a graphical frontend to gdb and a few other debuggers (like jdb). ddd's UI is straight out of the 90s era of commercial Unices, but I prefer it to gdb since it visualizes source code with breakpoints and the ip and has some nice variable displaying / plotting features (ie it's very easy to visualize a matrix AS a matrix if you're doing some graphics work)

edit: ddd also has a gdb prompt at the bottom, so you really don't lose much by using ddd over gdb unless you can't run an X server

cgdb is a nice visualization frontend too: <http://cgdb.github.com/>;

And for the die hard Emacs users there's: http://emacs-fu.blogspot.com/2009/02/fancy-debugging-with-gd...

I generally try to refrain from bringing up Emacs in threads that have nothing to do with it (since Emacs does everything) but I was pleasantly surprised by its gdb support and I have used it extensively in the past.

How does this compare to gdb TUI? For the most part I find TUI adequate but I'm always open to alternatives.

One nice thing about printf debugging is that your eyes and brain never leave the code. There is mental overhead in involving a third entity (in addition to the code and command line) which is the debugger.

Obviously, if the compile/execute loop is cumbersome then GDB will save a ton of time. But when the loop is fast, I find printf-ing to be effective and easy on the brain since you focus 100% on the code.

I don't follow how writing `printf` and watching the output in the console is 100% code when a debugger will stop at `debug(ger);` and show you the surrounding code in context with the output (and more output is accessible in far less time).

I guess it depends on the college. My ECE intro to programming class taught gdb very early, basically right after we learned the basics of C. I thought it was pretty neat but it never really seemed like a huge advantage over printing, especially after I wrote a few logging macros.

I can't believe how much time I wasted trying to debug C and C++ code in college with nothing more than printf and cout.

You say this as if this practice also isn't prevalent in working and experienced programmers also :)

It's portable to almost all languages and runtimes. :)

    watch -location ptr->member

This is perhaps the most overlooked feature of gdb.

GDB's not the only debugger out there. I think the real limitation is lack of debug methodology in general. I've discovered numerous features of proprietary debuggers just by thinking "I wish the tool could do X" only to find out that it already could.

GDB tip #1: gdb -tui (or cgdb if you're on Mac).

If you're on a Mac (pre 10.8, which unfortunately messes things up), I recommend biting the bullet and reinstalling gdb. The process is a bit annoying[0], but tui mode is worth the effort.

[0] http://sourceware.org/gdb/wiki/BuildingOnDarwin

Reply on news.ycombinator.com