2009-02-03

fancy debugging with gdb

In emacs, you can start debugging your application with M-x gdb. If you come from a Eclipse/Visual Studio-background, you may find the experience somewhat spartan -- and the Spartans are known for many things, but debugging is not one of them. Still, I have debugged that way for years, until I only recently (really!) discovered gdb-many-windows. It's simple; start gdb inside emacs as you'd do normaly (M-x gdb), and after that, call M-x gdb-many-windows. This will split your frame ('window') in six buffers ('sub-windows'), something like the following:
gdb commandslocal variables / registers
source code
stackbreakpoints
I am usually a bit skeptical about putting too many GUI-distractions between me and my code, but this is really useful! All the information I need at my fingertips. Emacs is a place full of hidden treasures.

If we look at gdb itself, and compare it with e.g. the Visual Studio-debugger, there are still many features missing, even with gdb-many-windows. Of course, one could easily dismiss fancy debuggers as leading to bad programming practices - and there is some truth in that. But I think there is real value in at least some of the features. So, it's nice to see that there is progress in this area. One example is Python scripting support. Using that, it's much easier to have gdb print something reasonable when looking at std::string-objects or GErrors. Now if only we could use Elisp instead of Python...

If you are new to gdb, I would recommend you to read the GDB Tutorial, and after that the GDB User Manual. Gdb is a very powerful tool, but it requires some learning. Just like emacs.

14 comments:

Anonymous said...

Of course, one could easily dismiss fancy debuggers as leading to bad programming practices - and there is some truth in that.

I'm curious what argument one could have for this. "You shouldn't have made the mistake in the first place"?

djcb said...

@WalterGR: well, some people (notably Linus Torvalds) have suggested that debuggers encourage fixing symptoms rather than fully understanding the problem -- e.g., just adding a NULL check to fix a crash rather than understanding why some var was NULL in the first place.

some academic types might go as far as reminding us that when formally proofing the correctness of your code, no debugger will be needed.

there is some truth to that, but it's simply not very practical; even if we hold our own code to such high standards, we still might have to deal with other people's code. then, a debugger might be by far the most efficient way to gain some insight.

Laurent Oget said...

"If you want more effective programmers, you will discover that they should not waste their time debugging, they should not introduce the bugs to start with."

Dijkstra
http://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html

"Already now, debugging strikes me as putting the cart before the horse: instead of looking for more elaborate debugging aids, I would rather try to identify and remove the more productive bug-generators!"

Dijkstra
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD303.html

Bill Night said...

@Laurent: I once heard Dijkstra say that the world would be a better place if computer programs had to be chiseled in marble.

I don't agree with that, do you? Even if you prove your program is correct, maybe there's a bug in your proof or assumptions. Debugging is a necessary skill.

Abhijith said...

Can you tell me which color theme that is? Looks nice.

Anonymous said...

"If you want more effective programmers, you will discover that they should not waste their time debugging, they should not introduce the bugs to start with." --Dijkstra

This is true, but misleading in this context. There's a difference between "debugging" and "debuggers". The most common use I have for a sophisticated debugger is to step through a working program to see what it's doing, and how. This is, arguably, not debugging. There's plenty of use for fancy debugger integration, without flying afoul of Dijkstra.

djcb said...

@Abhijith: the color theme is basically the one in http://emacs-fu.blogspot.com/2009/03/color-theming.html

Anonymous said...

Hi there, I'm doing some development for GDB in Emacs as Google Summer of Code project, check out http://emacswiki.org/emacs/GDB-MI/

djcb said...

@Джус: looks very interesting... good luck!

Anonymous said...

I always laugh when I see this nonsense about debuggers creating bad habits. They encourage GOOD habits - the ability to step through your own code and examine the status anywhere any time. In addition, all this academic nonsense about "proving code" is all well and good but in the real world a lot of programmers are working on other peoples code and a debugger is invaluable in stepping through and analyzing the execution paths for different source data in addition to setting HW break points on know data combinations which cause crashes - something that can save days of effort when used competently. Dijkstra or whoever. Unfortunately GDB is a mess. Its a dinosaur with an awful UI and the emacs many windows UI is a kludge on a kludge. None of the step commands are available in the source window which is where you want to be. Focus switching drives you crazy as you struggle to get back to the input gud buffer. Not nice at all.

Anonymous said...

Step commands are available in any window of Emacs GDB UI, not just source.

Anonymous said...

@Anonymous: Step and other GDB commands are on the Emacs toolbar. Window management is indeed a problem. But GDB and GDB in Emacs are free software and many people find them useful. If you don't, you can choose not to use them or you can choose to improve them. Please don't simply bad mouth them though. It's just too easy.

jqb said...

some people (notably Linus Torvalds) have suggested that debuggers encourage fixing symptoms rather than fully understanding the problem -- e.g., just adding a NULL check to fix a crash rather than understanding why some var was NULL in the first place.

That's utterly irrational. Debuggers are tools for finding bugs; they have no bearing on how the bug is fixed. In order to understand why some var was NULL in the first place, you have to first know that the var was NULL -- that that was the cause of the failure. Once you know that, you have a variety of ways to proceed; debuggers are neutral as to which one you pick.

Likewise for Dijkstra's comment ... he didn't say that debuggers lead to bad programming practices, he just said that programmers should learn to to program properly so debuggers are less needed. Also, language designers should learn how to design languages -- there are designs that make NULL references virtually impossible (by adding a pointer-or-nil type and removing nil from the range of the standard pointers).

Anonymous said...

I am having trouble entering commands associated with a breakpoint. In the gdb command window, I say breakpoint 2 (for example) and enter my commands but gdb never recognizes the end command so entering commands hangs forever. Is there some trick to ending the commands?