Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning C with gdb

hackerschool.com

Post reply on HN
Print view View original

51–60 of 98 posts

Re: Learning C with gdb

#51

Post by tmurray »

dkhenry wrote: post #26
jobu wrote: post #24

Earlier 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.

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.

Re: Learning C with gdb

#52

Post by stonefroot »

cfallin wrote: post #46
stonefroot wrote: post #28

Earlier quoted context omitted.

Can I do this with a hand-written assembly program, i.e. not necessarily one that has been compiled with as and subject to GNU default optimisations or "constraints"?

The commands you want are "stepi" (single-step one instruction), "disass" (disassemble at the current point in the program), and "info registers" (show you what's in all of the registers). These work equally well for hand-written assembly and for any arbitrary compiled program.

cfallin: many, many thanks.

I guess should read the gdb manual, and, if it's anything like the as manual (which I've learned is not always the full story), the source too.

Re: Learning C with gdb

#53

Post by psykotic »

dkhenry wrote: post #10

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.

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

Re: Learning C with gdb

#55

Post by happy4crazy »

psykotic wrote: post #53
dkhenry wrote: post #10

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.

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

Re: Learning C with gdb

#56

Post by mtoddh »

wildmXranat wrote: post #48

In addition to the gdb command, what would be a good GUI front-end for it ?

Emacs actually integrates pretty nicely with gdb. Just split the source file being debugged horizontally and fire up gdb in the other window:

Split the windows horizontally: C-x 2 Switch to the other window: C-x o Fire up gdb: M-x gdb

You can set breakpoints with C-x . Emacs will show an arrow next the source line about to be executed.

Re: Learning C with gdb

#57

Post by edge17 »

wildmXranat wrote: post #48

In addition to the gdb command, what would be a good GUI front-end for it ?

i'm sort of in between on this. I really don't like using the graphical debugger in xcode, but it is great when you have to dig around on multiple threads. I used ddd a bit, but always ended up just reverting back to cmdline gdb.

typically though, the performance of the graphical debugger is pretty lousy compared to commandline, and (in the case of xcode) it doesn't do everything. Knowing how to navigate yourself on the commandline is very beneficial, especially when you need to [for lack of better words] rip the shit out of something, inject chunks of memory, or forcibly reproduce bugs that don't happen often.

That being said, I have heard that visual studio is amazing. For some reason I've never developed on Windows platforms so I've never had the opportunity to use the debugger.

I'd be curious to hear other people's opinions/expereinces. I'll freely admit that I use the tools I use because I've grown comfortable with them.

Re: Learning C with gdb

#58

Post by vidarh »

dkhenry wrote: post #10

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.

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.

Re: Learning C with gdb

#59

Post by edge17 »

mtoddh wrote: post #56
wildmXranat wrote: post #48

In addition to the gdb command, what would be a good GUI front-end for it ?

Emacs actually integrates pretty nicely with gdb. Just split the source file being debugged horizontally and fire up gdb in the other window: Split the windows horizontally: C-x 2 Switch to the other window: C-x o Fire up gdb: M-x gdb You can set breakpoints with C-x . Emacs will show an arrow next the source line about to be executed.

yea, agree with this. emacs integration is very nice. as a side note, if you're particularly aggressive with gdb or the project you're working on is very large it helps to increase the buffer size significantly

Re: Learning C with gdb

#60

Post by johnrob »

jobu wrote: post #24
dkhenry wrote: post #10

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.

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.

Post reply on HN