LWN: Comments on "GDB 7.0 released"

GDB 7.0 released

MichaelSnyder — Sun, 18 Oct 2009 12:16:46 +0000

There has just been posted a tutorial page for gdb reverse debugging:
http://www.sourceware.org/gdb/wiki/ProcessRecord/Tutorial

GDB 7.0 released

jwakely — Thu, 15 Oct 2009 11:33:21 +0000

GDB can only present the information present in the debug info, so if GCC is just slapping in the fully expanded instantiated types, then that's all GDB can give the user.

... and this isn't true. GDB can show a more useful representation of data structures than simply listing all the bases and members, and that's exactly what the new python pretty printing does.

GDB 7.0 released

jwakely — Thu, 15 Oct 2009 08:56:56 +0000

A lot of that is GCC's fault, really. GDB can only present the information present in the debug info, so if GCC is just slapping in the fully expanded instantiated types, then that's all GDB can give the user.

GCC has to "slap in" the full type name for the linker, typedefs do not affect the name the linker uses.

GDB needs a big push in the debug info department.

You mean GCC, right? It's getting a big push, see http://gcc.gnu.org/wiki/Var_Tracking_Assignments

It could use a big push in the compile time error quality, too, for that matter.

See http://gcc.gnu.org/wiki/Better_Diagnostics - although it's easy to say diagnostics should be better, it's a lot harder to suggest specific improvements.

GDB 7.0 released

elanthis — Thu, 15 Oct 2009 08:26:00 +0000

GDB needs a big push in the debug info department. It could use a big push in the compile time error quality, too, for that matter.

great news about reverse debugging

nix — Fri, 09 Oct 2009 22:46:40 +0000

i.e., a reversible VM (with the reversibility interface being GDB,
definitely a good decision.)

great news about reverse debugging

MichaelSnyder — Fri, 09 Oct 2009 18:35:27 +0000

No, but VMware supports reverse *debugging*, with gdb.
You run gdb on the host, and debug the guest (either user
process or kernel). When you say "reverse-continue" in gdb,
VMware executes the guest backward until it hits a breakpoint
or watchpoint.

GDB 7.0 released

bronson — Fri, 09 Oct 2009 15:07:29 +0000

> though if gdb has trouble with that, it'll have trouble with longjmp too.

Not true. An exception unwinds the stack calling destructors as it goes. Longjmp just restores registers and jumps up the stack. They're very different beasts.

C++ Exception handling is actually quite complex with a number of unintuitive gotchas. Sadly, it's been a great source of compiler bugs too.

GDB 7.0 released

cry_regarder — Fri, 09 Oct 2009 13:56:41 +0000

We had this in a commercial compiler ($100K plus for reverse capability) in PL/I, Fortran, and COBOL back in 1994 on IBM ES-9000... It was insanely awesome for debugging code written by your grandfather :-)

Cry

GDB 7.0 released

sspr — Fri, 09 Oct 2009 09:38:12 +0000

Thank you for this informative comment. Reading these kind of comments (and articles!) is exactly what makes me stick&subscribe to LWN.

GDB 7.0 released

nix — Fri, 09 Oct 2009 09:07:45 +0000

Well, another problem is that GDB tended to use the full expanded names for all these types, rather than hiding things which are not referenced in the source code but only via default template parameters (very common: e.g. allocators in the STL). This tends to make trivial things like 'cout' or 'list<string>' into multiline what-the-hell-is-that horrors. (This was fixed for diagnostic output some time ago, but I haven't done much C++ debugging recently so I'm not sure if GDB fixed it similarly.)

GDB 7.0 released

nix — Fri, 09 Oct 2009 09:05:49 +0000

Forget longjmp. With the debugging information currently supplied in all released GCCs, GDB has trouble with variables that transition between registers and memory more than once (i.e. most of them in complex functions). The var-tracking branch for GCC should fix this, hopefully.

Regarding the constructors, the C++ ABI defines three types of constructor: complete object constructors, base object constructors, and complete object allocating constructors (but the latter type is optional and GCC never generates them). GCC somewhat confusingly calls the former two types 'in-charge' and 'not-in-charge' constructors, and these are the names GDB uses for them.

Complete object constructors are supposed to dig out the appropriate VTT pointer during virtual inheritance and call the base object constructor: however, released GCCs instead just clone the entire function body (see gcc/cp/class.c:build_clone()). When he implemented this, Mark Mitchell mentioned that

It would be better to have multiple entry points into a single routine, but we don't have support for that yet in the back-end, and we can always change the method used later without breaking the ABI.

but nobody ever implemented this, so when you set a breakpoint in a constructor it ends up in two places, not one, and this confuses the hell out of most GDBs.

(Mind you, GDB has to handle this anyway even if the in-charge constructor does change to call the not-in-charge one: GCC can do cloning of arbitrary functions now to aid constant propagation and inlining, even across translation unit boundaries if whole-program optimization is on, and I'd expect that to confuse GDB in exactly the same way as in-charge/not-in-charge constructors always have. I haven't checked to see if this has been fixed in the last year.)

great news about reverse debugging

nix — Fri, 09 Oct 2009 08:43:10 +0000

A reversible VM isn't *quite* the same thing. (There was a reversible VM project for Linux based on UML, called ReVirt, but it was an academic project so it suffered the usual fate of such and died as soon as the funding went away. I keep wishing someone would bring one back again, but, admittedly, without ever actually doing anything toward that end myself.)

GDB 7.0 released

njs — Fri, 09 Oct 2009 05:14:51 +0000

IME the biggest problem with debugging C++ in gdb -- at least traditionally -- is that C++ programs tend to use complex opaque types for everything (e.g., std::string, std::map, ...). In theory this isn't a problem, all the data is there and accessible through C-callable functions, but in practice it's hellish.

IIRC the new Python scripting stuff is supposed to help with this.

GDB 7.0 released

quotemstr — Fri, 09 Oct 2009 01:50:13 +0000

Fair enough on exception handling (though if gdb has trouble with that, it'll have trouble with longjmp too.)

But what's this double-constructor thing?

great news about reverse debugging

MichaelSnyder — Thu, 08 Oct 2009 23:32:26 +0000

VMware workstation 7.0 supports reverse debugging in both gdb (for Linux VMs) and Virtual Studio (for M$oft VMs).

GDB 7.0 released

MichaelSnyder — Thu, 08 Oct 2009 22:55:09 +0000

You're thinking of checkpoint/restart. This is completely different.
The present "reverse debugging" feature set allows you to do reverse-step,
reverse-next, reverse-continue etc., running backward to any breakpoint
or watchpoint, or just stepping backward by a single instruction if you
choose. You're not restricted to stopping only at previously designated
checkpoints.

great news about reverse debugging

nix — Thu, 08 Oct 2009 22:36:56 +0000

ooo! it can use chronicle-written databases! Yay!

(think 'persistent after-the-fact remote debugging')

GDB 7.0 released

nix — Thu, 08 Oct 2009 22:33:38 +0000

Differences that GDB has had trouble with include exception handling,
overloaded functions, the magic duplicate of every constructor that the
C++ ABI dictates (put a breakpoint on it and likely as not it'd land on
the wrong one)...

great news about reverse debugging

nix — Thu, 08 Oct 2009 22:32:23 +0000

I dunno. Do non-free debuggers implement reverse debugging? It's obviously
really killingly *useful* to developers, which is probably why it got
done :) (it also needs lots of storage, which is probably why it didn't
get done twenty years ago.)

GDB 7.0 released

ikm — Thu, 08 Oct 2009 21:59:42 +0000

Well the difference is a *huge* quantity of them in some larger C++ projects, all are very lengthy and convoluted, many of them being template instantiations etc. I remember trying to debug such projects in GCC and attempting to trace through a program was quite impossible, being horribly slow. And sometimes gdb would just end up segfaulting and asking whether I would want to debug the gdb itself. It was a pity, really. Don't know the state of affairs now -- that's why I asked. But some years ago the situation didn't look good.

GDB 7.0 released

oak — Thu, 08 Oct 2009 20:23:25 +0000

> There's no difference between debugging C and C++ programs, except that
C++ ones have funny symbol names. Assuming you can get past the name
mangling (and the thiscall calling convention*), what's the difference?

For example exception handling. Exception handler can crash when stack
has been unwound. A bit tricker to show callers then...

Project Archer's devel branch page lists some other issues they deal with.

GDB 7.0 released

robert_s — Thu, 08 Oct 2009 20:21:15 +0000

"I guess you just have to arrange for the thread to stop at a
time when it's not holding locks the rest of the program depends on"

Sounds like a great way to trigger and investigate race conditions that you'd never thought of.

GDB 7.0 released

cventers — Thu, 08 Oct 2009 19:51:09 +0000

Reverse debugging sounds very cool, but non-stop debugging sounds even
cooler to me. I guess you just have to arrange for the thread to stop at a
time when it's not holding locks the rest of the program depends on :p

GDB 7.0 released

quotemstr — Thu, 08 Oct 2009 19:47:05 +0000

There's no difference between debugging C and C++ programs, except that C++ ones have funny symbol names. Assuming you can get past the name mangling (and the thiscall calling convention*), what's the difference?

* which is practically identical to the fastcall convention used by some C code.

GDB 7.0 released

pranith — Thu, 08 Oct 2009 18:30:39 +0000

I tried the snapshot feature in 6.8 and it was a big letdown. After switching to the forked process, it mostly crashed. Never got it working.

GDB 7.0 released

JoeBuck — Thu, 08 Oct 2009 18:02:05 +0000

I've had pretty good experiences with gdb 6.8 and C++, certainly a big improvement over earlier versions.

GDB 7.0 released

ikm — Thu, 08 Oct 2009 16:44:30 +0000

Reverse debugging is sure cool, but does gdb still fall down on its knees when trying to debug any complex C++ program, perfomance- -- or sometimes even segfault-wise?

GDB 7.0 released

mjw — Thu, 08 Oct 2009 14:50:54 +0000

From the Project Archer Roadmap
http://sourceware.org/gdb/wiki/ProjectArcher

"# Fedora patches. Fedora has a big backlog of gdb patches. We will rebase these to a more recent gdb, integrate them into archer, and send them upstream as appropriate."

GDB 7.0 released

rahulsundaram — Thu, 08 Oct 2009 13:59:43 +0000

These were all patches that Red Hat contributed to GDB upstream. Should go away as Fedora inherits 0.7

GDB 7.0 released

arekm — Thu, 08 Oct 2009 13:52:53 +0000

No idea, fedora at least needs these - http://cvs.fedora.redhat.com/viewvc/devel/gdb/

GDB 7.0 released

coriordan — Thu, 08 Oct 2009 13:49:25 +0000

Were those patches used to give GDB the features which it now has in 7.0?

great news about reverse debugging

coriordan — Thu, 08 Oct 2009 13:47:14 +0000

The reverse-debugging feature was on FSF's high priority list for a good while - which usually indicates there's some acute problem of free software users/developers being drawn to some non-free software by this feature.

Glad to hear it's gotten done.

http://www.fsf.org/campaigns/priority.html

GDB 7.0 released

arekm — Thu, 08 Oct 2009 13:34:56 +0000

Are 107 Fedora gdb patches merged in or will distros still need to apply tons of patches to make it more useful?