GDB 7.0 released

Posted Oct 8, 2009 22:33 UTC (Thu) by nix (subscriber, #2304)
In reply to: GDB 7.0 released by quotemstr
Parent article: GDB 7.0 released

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

GDB 7.0 released

Posted Oct 9, 2009 1:50 UTC (Fri) by quotemstr (subscriber, #45331) [Link] (3 responses)

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?

GDB 7.0 released

Posted Oct 9, 2009 9:05 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

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

GDB 7.0 released

Posted Oct 9, 2009 9:38 UTC (Fri) by sspr (guest, #39636) [Link]

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

Posted Oct 9, 2009 15:07 UTC (Fri) by bronson (subscriber, #4806) [Link]

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