Having programmed a fair amount of C, I regret never learning properly how to use gdb. This article is quite helpful!
It's never too late to start.
Learning C with gdb
81–90 of 98 posts
Re: Learning C with gdb
#82gdb 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)?
Re: Learning C with gdb
#83GDB 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.
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.
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 :)
Re: Learning C with gdb
#84Earlier quoted context omitted.
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.
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.
Re: Learning C with gdb
#85Very interesting! But I'd say this is too dangerous because of the misleading conclusions that it'd "make" you realize.
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.
And maybe I am wrong, but even the author got mislead by it.
"I'm going to ignore why 2147483648 == -2147483648; the point is that even arithmetic can be tricky in C, and gdb understands C arithmetic."
That's actually the result of undefined behavior, and not so much a result or "how C integer arithmetic works".
I really liked the idea. I just think it may be misleading if the tool you're using is GDB.
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.
Re: Learning C with gdb
#86Earlier quoted context omitted.
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.
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).
Re: Learning C with gdb
#87Earlier quoted context omitted.
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.
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. :)
Re: Learning C with gdb
#88I want to be able to do this with assembly, e.g., see what is in each register as I step through the program.
You can use "layout asm" to see the dissassembly as you step through your program. "layout reg" will then split the view and show you the registers at the same time.
Re: Learning C with gdb
#89Very interesting! But I'd say this is too dangerous because of the misleading conclusions that it'd "make" you realize. 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 explorato…
That's not undefined, it's simply the bitwise representation of a 32 bits integer.
Re: Learning C with gdb
#90Earlier quoted context omitted.
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?
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 r…
cgdb is a nice visualization frontend too: http://cgdb.github.com/>