Release Digest: GNU, June 20, 2004Jun 21, 2004, 05:00 (0 Talkback[s])
There is a web page for GDB at:
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.
The credit must go to Shrinivas Atre, Jim Blandy, Joel Brobecker, Paul Brook, Kevin Buettner, David Carlton, Stephane Carrez, Michael Elizabeth Chastain, Albert Chin-A-Young, Randolph Chung, Stephen Clarke, Nick Clifton, Brendan Conoboy, Chris Demetriou, Dhananjay Deshpande, Ben Elliston, Christopher Faylor, Adam Fedor, Fred Fish, Orjan Friberg, Anthony Green, Jerome Guitton, Richard Henderson, Paul N. Hilfinger, Jim Ingham, Bernardo Innocenti, Daniel Jacobowitz, Andreas Jaeger, Jeff Johnston, Nick Kelsey, Mark Kettenis, David Lecomber, H.J. Lu, Michal Ludvig, Roland McGrath, Bryce McKinlay, Jason Merrill, Robert Millan, David S. Miller, Mark Mitchell, Alan Modra, Jason Molenda, David Mosberger, Atsushi Nemoto, Mark Newman, Rainer Orth, Pawel Ostrowski, Nick Roberts, Theodore A. Roth, Kei Sakamoto, Richard Sandiford, Peter Schauer, Andreas Schwab, Michael Snyder, Ian Lance Taylor, Corinna Vinschen, Kris Warkentin, Ulrich Weigand, James E Wilson, Jimi Xenidis, Elena Zannoni, and Eli Zaretskii along with all our testers and uses that who all contributed to the 6.1 release series.
Keep those fixes and improvements coming in! (See http://www.gnu.org/software/gdb/bugs/)
on behalf of the GDB Developers.
The TUI (Text-mode User Interface) is now built as part of a default GDB configuration. It is enabled by either selecting the TUI with the command line option "-i=tui" or by running the separate "gdbtui" program. For more information on the TUI, see the manual "Debugging with GDB".
Support has been added to allow you to specify breakpoints in shared libraries that have not yet been loaded. If a breakpoint location cannot be found, and the "breakpoint pending" option is set to auto, GDB queries you if you wish to make the breakpoint pending on a future shared-library load. If and when GDB resolves the breakpoint symbol, the pending breakpoint is removed as one or more regular breakpoints are created.
Pending breakpoints are very useful for GCJ Java debugging.
The files bfd/elf-bfd.h, gdb/dictionary.c and gdb/types.c contained non ISO-C code that stopped them being built using a more strict ISO-C compiler (e.g., IBM's C compiler).
Due to header problems with <sys/proc.h>, the file gdb/proc-api.c wasn't able to compile compile on an IRIX 5 system.
The shell script gdb/testsuite/gdb.stabs/configure lacked execute permission. This bug would cause configure to fail on a number of systems (Solaris, IRIX). Ref: server/519.
Older HPUX ANSI C compilers did not accept variable array sizes. somsolib.c has been updated to use constant array sizes.
GCC 3.3.2, on Solaris 2.7, includes the DW_EH_PE_funcrel encoding in its generated DWARF Call Frame Info. This encoding was causing GDB to panic, that panic has been fixed. Ref: gdb/1628.
When examining parameters in optimized shared library code generated by a mainline GCC, GDB would incorrectly report ``Variable "..." is not available''. GDB now correctly displays the variable's value.
Support for the mmalloc memory manager has been removed, as it conflicted with the internal gdb byte cache.
The AMD64 target now includes the %cs and %ss registers. As a result the AMD64 remote protocol has changed; this affects the floating-point and SSE registers. If you rely on those registers for your debugging, you should upgrade gdbserver on the remote side.
The SPARC target has been completely revised, incorporating the FreeBSD/sparc64 support that was added for GDB 6.0. As a result support for LynxOS and SunOS 4 has been dropped. Calling functions from within GDB on operating systems with a non-executable stack (Solaris, OpenBSD) now works.
GDB has a new C++ demangler which does a better job on the mangled names generated by current versions of g++. It also runs faster, so with this and other changes gdb should now start faster on large C++ programs.
GDB support for location expressions has been extended to support function arguments and frame bases. Older versions of GDB could crash when they encountered these.
GDB's support for nested types and namespaces in C++ has been improved, especially if you use the DWARF 2 debugging format. (This is the default for recent versions of GCC on most platforms.) Specifically, if you have a class "Inner" defined within a class or namespace "Outer", then GDB realizes that the class's name is "Outer::Inner", not simply "Inner". This should greatly reduce the frequency of complaints about not finding RTTI symbols. In addition, if you are stopped at inside of a function defined within a namespace, GDB modifies its name lookup accordingly.
M32R with SDI protocol
Known problems in GDB 6.1.1
See also: http://www.gnu.org/software/gdb/bugs/
build/1458: comple failed on hpux11
GDB 6.1 is known to have build problems on HP/UX 11.00 using the vendor supplied compilers (GDB does build on HP/UX 11.11, and using GCC).
gdb/1560: Control-C does not always interrupt GDB.
When GDB is busy processing a command which takes a long time to complete, hitting Control-C does not have the expected effect. The command execution is not aborted, and the "QUIT" message confirming the abortion is displayed only after the command has been completed.
gdb/931: GDB could be more generous when reading types C++ templates on input
When the user types a template, GDB frequently requires the type to be typed in a certain way (e.g. "const char*" as opposed to "const char *" or "char const *" or "char const*").
gdb/1512: no canonical way to output names of C++ types
We currently don't have any canonical way to output names of C++ types. E.g. "const char *" versus "char const *"; more subtleties arise when dealing with templates.
gdb/1516: [regression] local classes, gcc 2.95.3, dwarf-2
With gcc 2.95.3 and the dwarf-2 debugging format, classes which are defined locally to a function include the demangled name of the function as part of their name. For example, if a function "foobar" contains a local class definition "Local", gdb will say that the name of the class type is "foobar__Fi.0:Local".
This applies only to classes where the class type is defined inside a function, not to variables defined with types that are defined somewhere outside any function (which most types are).
gdb/1588: names of c++ nested types in casts must be enclosed in quotes
You must type
(gdb) print ('Foo::Bar') x
(gdb) print ('Foo::Bar' *) y
(gdb) print (Foo::Bar) x
(gdb) print (Foo::Bar *) y
gdb/1091: Constructor breakpoints ignored gdb/1193: g++ 3.3 creates multiple constructors: gdb 5.3 can't set breakpoints
When gcc 3.x compiles a C++ constructor or C++ destructor, it generates 2 or 3 different versions of the object code. These versions have unique mangled names (they have to, in order for linking to work), but they have identical source code names, which leads to a great deal of confusion. Specifically, if you set a breakpoint in a constructor or a destructor, gdb will put a breakpoint in one of the versions, but your program may execute the other version. This makes it impossible to set breakpoints reliably in constructors or destructors.
gcc 3.x generates these multiple object code functions in order to implement virtual base classes. gcc 2.x generated just one object code function with a hidden parameter, but gcc 3.x conforms to a multi-vendor ABI for C++ which requires multiple object code functions.
GDB's core code base has been updated to use a new backtrace mechanism. This mechanism makes it possible to support new features such DWARF 2 Call Frame Information (which in turn makes possible backtraces through optimized code).
Since this code is new, it is known to still have a few problems:
gdb/1505: [regression] gdb prints a bad backtrace for a thread
When backtracing a thread, gdb does not stop when it reaches the outermost frame, instead continuing until it hits garbage. This is sensitive to the operating system and thread library.
The MIPS and HPPA backtrace code has only very recently been updated to use GDB's new frame mechanism. At present there are still a few problems, in particular backtraces through signal handlers do not work.
People encountering problems with these architectures should consult GDB's web pages and mailing lists (http://www.gnu.org/software/gdb/) to see if there are updates.
PowerPC architecture support, in 6.1, does not use the new frame code.
Fortunately, PowerPC architecture support, in GDB's mainline sources, have been updated. People encountering problems should consider downloading a more current snapshot of GDB (http://www.gnu.org/software/gdb/current/).
The command "set prompt-escape-char" has been deleted. This command, and its very obscure effet on GDB's prompt, was never documented, tested, nor mentioned in the NEWS file.
Configurations that have been declared obsolete in this release have been commented out. Unless there is activity to revive these configurations, the next release of GDB will have their sources permanently REMOVED.