| gdb commands | local variables / registers |
| source code | |
| stack | breakpoints |
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:
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"?
@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.
"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
@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.
Can you tell me which color theme that is? Looks nice.
"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.
@Abhijith: the color theme is basically the one in http://emacs-fu.blogspot.com/2009/03/color-theming.html
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/
@Джус: looks very interesting... good luck!
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.
Step commands are available in any window of Emacs GDB UI, not just source.
@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.
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).
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?
Post a Comment