GDB 7.0 released

[Posted October 8, 2009 by corbet]

From:		Joel Brobecker <brobecker-AT-adacore.com>
To:		gdb-announce-AT-sourceware.org
Subject:		GDB 7.0 released!
Date:		Tue, 6 Oct 2009 10:40:09 -0700

            GDB 7.0 released!

Release 7.0 of GDB, the GNU Debugger, is now available via anonymous
FTP.  GDB is a source-level debugger for Ada, C, C++, Objective-C,
Pascal and many other languages.  GDB can target (i.e., debug programs
running on) more than a dozen different processor architectures, and GDB
itself can run on most popular GNU/Linux, Unix and Microsoft Windows
variants.

You can download GDB from the GNU FTP server in the directory:

        ftp://ftp.gnu.org/gnu/gdb

The vital stats:

  Size  md5sum                            Name
  17MB  3386a7b69c010785c920ffc1e9cb890a  gdb-7.0.tar.bz2
  23MB  67b4144db385620d7b93f7b0c26800f7  gdb-7.0.tar.gz

There is a web page for GDB at: 

        http://www.gnu.org/software/gdb/

That page includes information about GDB mailing lists (an announcement
mailing list, developers discussion lists, etc.), details on how to
access GDB's CVS repository, locations for development snapshots,
preformatted documentation, and links to related information around
the net.  We will put errata notes and host-specific tips for this release
on-line as any problems come up.  All mailing lists archives are also
browsable via the web.

GDB 7.0 is packed with new platforms being supported, major new features, 
enhancements and bug fixes. For a complete list and more details on each
iteam, please see the gdb/NEWS file.

The new native configurations being supported are:

  * x86/x86_64 Darwin
  * x86_64 MinGW

Support for the following targets has been added:

  * Lattice Mico32                  
  * x86/x86_64 DICOS                
  * S+core 3                        
  * The remote stub now supports x86 Windows CE

The major new features are:

  * Python scripting support
  * Reverse debugging, Process record and replay
  * Non-stop debugging
  * Multi-architecture debugging
  * Multi-inferior, multi-process debugging
  
It also features many enhancements and bug fixes, including:

  * GDB now has an interface for JIT compilation
  * Tracepoints may now be conditional
  * Multi-byte and wide character set support
  * New /r and /m modifiers for the "disassemble" command
  * Automatic retrieval of shared library files from remote targets
  * Inlined functions are now supported
  * New remote protocal packets
  * GDB is now able to read compressed debug sections
  * Thread switching is now supported on Tru64
  * Ada task switching is now supported
  * New features in gdbserver, the GDB remote stub
  * New command to stop execution when a system call is made

-- 
Joel

GDB 7.0 released

Posted Oct 8, 2009 13:34 UTC (Thu) by arekm (guest, #4846) [Link] (4 responses)

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

GDB 7.0 released

Posted Oct 8, 2009 13:49 UTC (Thu) by coriordan (guest, #7544) [Link] (2 responses)

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

GDB 7.0 released

Posted Oct 8, 2009 13:52 UTC (Thu) by arekm (guest, #4846) [Link] (1 responses)

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

GDB 7.0 released

Posted Oct 8, 2009 13:59 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

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

GDB 7.0 released

Posted Oct 8, 2009 14:50 UTC (Thu) by mjw (subscriber, #16740) [Link]

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

great news about reverse debugging

Posted Oct 8, 2009 13:47 UTC (Thu) by coriordan (guest, #7544) [Link] (6 responses)

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

great news about reverse debugging

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

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

great news about reverse debugging

Posted Oct 8, 2009 23:32 UTC (Thu) by MichaelSnyder (guest, #61265) [Link] (3 responses)

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

great news about reverse debugging

Posted Oct 9, 2009 8:43 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

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

great news about reverse debugging

Posted Oct 9, 2009 18:35 UTC (Fri) by MichaelSnyder (guest, #61265) [Link] (1 responses)

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.

great news about reverse debugging

Posted Oct 9, 2009 22:46 UTC (Fri) by nix (subscriber, #2304) [Link]

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

great news about reverse debugging

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

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

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

GDB 7.0 released

Posted Oct 8, 2009 16:44 UTC (Thu) by ikm (guest, #493) [Link] (17 responses)

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

Posted Oct 8, 2009 18:02 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] (3 responses)

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

GDB 7.0 released

Posted Oct 8, 2009 18:30 UTC (Thu) by pranith (subscriber, #53092) [Link] (2 responses)

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

Posted Oct 8, 2009 22:55 UTC (Thu) by MichaelSnyder (guest, #61265) [Link] (1 responses)

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.

GDB 7.0 released

Posted Oct 9, 2009 13:56 UTC (Fri) by cry_regarder (subscriber, #50545) [Link]

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

Posted Oct 8, 2009 19:47 UTC (Thu) by quotemstr (subscriber, #45331) [Link] (12 responses)

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

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)

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.

GDB 7.0 released

Posted Oct 8, 2009 19:51 UTC (Thu) by cventers (guest, #31465) [Link] (1 responses)

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

Posted Oct 8, 2009 20:21 UTC (Thu) by robert_s (subscriber, #42402) [Link]

"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

Posted Oct 18, 2009 12:16 UTC (Sun) by MichaelSnyder (guest, #61265) [Link]

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