False Prophets

I have just committed a patch for inlined function support in GDB.

This is pretty neat stuff, if you ask me (but don’t - I’m obviously biased :-). GDB now treats inlined functions like normal functions whenever the optimized code - and debug information - permit it. For instance:

• The backtrace shows inlined functions. You can see their arguments and local variables. You can use up to look at the inlined function’s call site, instead of having to guess.
• If you’re stopped at a call to an inlined function, step will take you into it. next will skip it. next in particular is a little flaky; the logical operation doesn’t have a clear meaning in the presence of scheduling optimizations, which interleave the inlined function’s code with the code of its caller. So you may have to next a good number of times to get where you’re going, but at least it shouldn’t ever take you into the function you’re nexting over.
• finish will take you out of the inlined function. That may mean back to its call site, or on to the next line of code if the call site had no more work to do.

Of course, all of this neat functionality relies on debug information to understand the mapping from optimized binary back to user source code. The debug info used is DWARF, which is a modern and mostly cross-platform standard (obvious exception: Microsoft). None of this was possible using the older stabs debug format. (At least not stabs as understood by GDB; Sun may have had similar extensions to stabs for DBX.)

The more optimized your program is, the stranger that mapping and the worse using GDB on your program. There are two major causes of this: deficiencies in GDB’s understanding of the debug info, and deficiencies in GCC’s generation of it. This is a big step forward on the GDB side. Similarly huge steps are in progress in GCC, for instance Alexandre Oliva’s VTA (”variable tracking assignments”) branch. And having better GDB support and test cases will, I hope, help the GCC developers to fix more debug info generation bugs.

This patch is one of many recent improvements to GDB. I think there’s been a real sea change in the GDB community; GDB development was slow for many years, with much of the attention on avoiding bit-rot and occasional ports to new CPU architectures. But now exciting things are happening again! There’s a number of factors I can point at to explain the change. A big one is the recent work on multi-process and non-stop debugging, by Pedro Alves and Stan Shebs (and others!). That has convinced others, both individuals and corporations, that the GDB project is worth spending time on. There’s been a cascade of interest, leading to e.g. Python scripting support in the development tree. Finally, STL pretty-printers! Another big factor has been the emergence, and re-emergence, of active maintainers with a good global understanding of GDB; people like Pedro, Stan, Joel Brobecker, Ulrich Weigand, and Tom Tromey. They’ve made the lists a friendlier and much more responsive place than I can ever remember since I started working on GDB in 2001. There’s a host of other new contributors, too - sorry for not listing you all, guys, but please don’t think you aren’t appreciated.

It’s a good time to get involved! Ever been frustrated by something GDB did, or didn’t do? Drop us a line at gdb@sourceware.org, file a bug (thanks to Tom Tromey, we now have our own bugzilla instance instead of GNATS), or lend a hand.

One recently recurring topic is source control. Yes, GDB is still in CVS. The reason is modules - nothing else has modules that work quite like CVS’s, and the “src” repository relies heavily on them. It’s going to take some changes to the top level build scripts, some developer training, and some twisty management scripts to get us into another source control system. But I’m holding out hope it will happen in the next year.

When will you see these neat things in Debian, you ask? Pretty soon. GDB 7 will hopefully come out this Fall, and I think it’s ready to go into Debian unstable at this point. I’ve had packages of the Python scripting branch in experimental for a while; not all of that branch has been merged to trunk yet, but enough has to be handy. Once this is in unstable, hopefully we can make any needed tweaks to the libstdc++ packaging to help GDB find the new pretty-printers that ship with it.