Also cool to play around with are the various options that let GCC (and presumably LLVM) show you the various compilation stages of your C code. You can even spit out the C and resulting assembly side-by-side.<p>I haven't had the time to play with this, but Part 4 of the excellent "Unix as IDE" series [1] goes into it and I'm sure there's more around the web.<p>Another <i>really</i> fun way to get into the underlying assembler that the C compiler generates is Vidar Hokstad's "Writing a compiler in Ruby, bottom up" [2]. This series involves writing little C functions, compiling them to the simplest assembly you can get, then writing a ruby compiler (in Ruby!) that emits that assembly. Some people have objections to the approach, but it's really quite nifty. I especially like it because it's really refreshing to see a compiler tutorial that <i>doesn't</i> start with the lexer and parser.<p>[1] <a href="http://blog.sanctum.geek.nz/unix-as-ide-compiling/" rel="nofollow">http://blog.sanctum.geek.nz/unix-as-ide-compiling/</a>
[2] <a href="http://www.hokstad.com/compiler" rel="nofollow">http://www.hokstad.com/compiler</a>
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.
If you enjoyed this, then you'll certainly enjoy the programming chapter of 'Hacking: The Art of Exploitation' by Jon Erickson (<a href="http://en.wikipedia.org/wiki/Hacking:_The_Art_of_Exploitation" rel="nofollow">http://en.wikipedia.org/wiki/Hacking:_The_Art_of_Exploitatio...</a>). The first half of the book is a similar exploration of C programming using GDB to explain everything. Recommended.
I'm surprised nobody's linked the gdb reference card. It's fairly old now, but it's still handy if you don't use gdb that often:<p><a href="http://users.ece.utexas.edu/~adnan/gdb-refcard.pdf" rel="nofollow">http://users.ece.utexas.edu/~adnan/gdb-refcard.pdf</a>
The visual debugger in both Eclipse CDT and Visual C++ let you do things like create breakpoints, step through your program, monitor variable values, even create conditional breakpoints that are triggered when a particular lineof code is executed n number of times or when some particular expression involving variables in the local context of the breakpoint turn true.<p>My question is, what advantages do you get in using gdb directly through the CLI rather than through an IDE? (like Eclipse/NetBeans which itself uses gdb for C/C++ debugging, but has a nice graphical UI for it.)
While graphical debuggers are great overall, there are times when I prefer to get down to the command line and do my debugging there. And quite surprisingly, I don't lose much efficiency there, either.<p>But then, this could be the story of most command line utilities: Seems fiddly at first, but actually it is quite usable and often times more convenient than all those whiz-bang graphical tools.
There was a debugger posted here to HN awhile back that actually displayed structs and pointers graphically. What was the name of that project, and is it still around? I was trying to find it the other day. I thought that was a dynamite tool for students.<p>With LLVM, we should be able to have a REPL for C. as a pedagogical tool.
lldb would be even better for using instead of gdb because lldb actually uses clang's parsing for everything.<p>I was watching an Apple talk on lldb which explained this in more detail, and it shows a lot of promise for a debugger to have a full C compiler inside of it.
This is pretty neat, though I found myself doing similar things in small test files when I was first learning C and printing the results. C compile times suck, but with like a 10 line program or so to toy with a language semantic, it was practically instant (in 2007). But then again I had never used a dynamic language like Ruby/Python before then so I didn't know better.<p>More people should be hopping on this bandwagon though because debuggers are awesome. I typically find myself using `po` the most in LLDB (Xcode, iOS development) but it's insanely useful especially when Xcode refuses to show me the values of something I want in the Variables View, ex. NSDictionary keys/values, objects in an NSArray, etc. I'll also use it sometimes to execute simple commands like `[myArrayObject count]` when the Variables View refuses to show me property values. Sometimes Xcode's GUI bits just don't cut it!<p>There's more info on what you can do with LLDB here:
<a href="http://lldb.llvm.org/tutorial.html" rel="nofollow">http://lldb.llvm.org/tutorial.html</a><p>And if you've used GDB, this might be of use:
<a href="http://lldb.llvm.org/lldb-gdb.html" rel="nofollow">http://lldb.llvm.org/lldb-gdb.html</a>
It's great for instant feedback but IMHO interactive programming makes it easy (or at least easier) to be lazy. If you get used to coding by trial and error you'll never really understand the language or the problem you're trying to solve, you'll just keep trying things until it works. I know that's not how everyone approaches programming but I've seen it far too often to dismiss it
There's also CINT (a C interpreter), which can be used as a REPL:<p><a href="http://root.cern.ch/drupal/content/cint" rel="nofollow">http://root.cern.ch/drupal/content/cint</a>
for the somewhat-graphically-inclined, gdb mode in emacs has the much under-advertized 'M-x gdb-many-windows' which shows your stack, local variables, breakpoints etc. in separate 'windows'.
I find the basic c tutorials a nice refresher. Here is one from a few weeks back on memory addresses and pointers in c <a href="http://news.ycombinator.com/item?id=4399498" rel="nofollow">http://news.ycombinator.com/item?id=4399498</a> .
gdb is like acid, works everywhere : <a href="https://stripe.com/blog/exploring-python-using-gdb" rel="nofollow">https://stripe.com/blog/exploring-python-using-gdb</a>
Very interesting! But I'd say this is too dangerous because of the misleading conclusions that it'd "make" you realize.<p>Relying on what is printed out of printing a pointer value (which is not what the author is doing) is also misleading. Concluding stuff like "the size of an int is 4" or "size of double is 8" is also misleading. Again, it's not the conclusions the author is realizing, but for someone doing exploratory programming, it may be the case since the point of exploratory programming is learning by seeing how the system responds to the things you're doing.<p>And maybe I am wrong, but even the author got mislead by it.<p>"I'm going to ignore why 2147483648 == -2147483648; the point is that even arithmetic can be tricky in C, and gdb understands C arithmetic."<p>That's actually the result of undefined behavior, and not so much a result or "how C integer arithmetic works".<p>I really liked the idea. I just think it may be misleading if the tool you're using is GDB.<p>It'd be interesting a tool which allowed that sort of exploratory programming, but taking into consideration undefined behavior, unspecified things and implementation defined behavior.
Does anyone else think debuggers are awesome for learning how programs/languages work? Its pretty much always the first thing I do, even before reading docs, build and debug.
Here's a more full-featured C++ REPL: <a href="http://root.cern.ch/drupal/content/what-cling" rel="nofollow">http://root.cern.ch/drupal/content/what-cling</a>
I just got back into C programming after a long absence. Programming with Eclipse CDT is the way to go, at least for starting out. The debugger is great.
gdb is one of those tools that I regret never learning because I've always had an IDE. I was able to follow the examples here well enough, but the array assignment causes gdb to crash in Cygwin. Does anyone have any suggestions for how to overcome that (short of installing a vm & a real linux)?