GDB 7.0 released [LWN.net]

GDB 7.0 released

Posted Oct 8, 2009 20:23 UTC (Thu) by oak (guest, #2786) [Link]

> 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

Posted Oct 8, 2009 21:59 UTC (Thu) by ikm (guest, #493) [Link]

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

Posted Oct 8, 2009 22:33 UTC (Thu) by nix (subscriber, #2304) [Link] (4 responses)

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.

GDB 7.0 released

Posted Oct 9, 2009 5:14 UTC (Fri) by njs (subscriber, #40338) [Link] (4 responses)

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

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

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

Posted Oct 15, 2009 8:26 UTC (Thu) by elanthis (guest, #6227) [Link] (2 responses)

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.

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.

GDB 7.0 released

Posted Oct 15, 2009 8:56 UTC (Thu) by jwakely (subscriber, #60262) [Link] (1 responses)

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

Posted Oct 15, 2009 11:33 UTC (Thu) by jwakely (subscriber, #60262) [Link]

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.