What has changed since GDB-3.5?
(Organized release by release)
-*** Changes in GDB-4.7:
+*** Changes in GDB-4.9:
+
+ * Testsuite
+
+This is the first GDB release which is accompanied by a matching testsuite.
+The testsuite requires installation of dejagnu, which should be available
+via ftp from most sites that carry GNU software.
+
+ * C++ demangling
+
+'Cfront' style demangling has had its name changed to 'ARM' style, to
+emphasize that it was written from the specifications in the C++ Annotated
+Reference Manual, not necessarily to be compatible with AT&T cfront. Despite
+disclaimers, it still generated too much confusion with users attempting to
+use gdb with AT&T cfront.
+
+ * Simulators
+
+GDB now uses a standard remote interface to a simulator library.
+So far, the library contains simulators for the Zilog Z8001/2, the
+Hitachi H8/300, H8/500 and Super-H.
+
+ * New targets supported
+
+H8/300 simulator h8300-hitachi-hms or h8300hms
+H8/500 simulator h8500-hitachi-hms or h8500hms
+SH simulator sh-hitachi-hms or sh
+Z8000 simulator z8k-zilog-none or z8ksim
+IDT MIPS board over serial line mips-idt-ecoff
+
+Cross-debugging to GO32 targets is supported. It requires a custom
+version of the i386-stub.c module which is integrated with the
+GO32 memory extender.
+
+ * New remote protocols
+
+MIPS remote debugging protocol.
+
+ * New source languages supported
+
+This version includes preliminary support for Chill, a Pascal like language
+used by telecommunications companies. Chill support is also being integrated
+into the GNU compiler, but we don't know when it will be publically available.
+
+
+*** Changes in GDB-4.8:
+
+ * HP Precision Architecture supported
+
+GDB now supports HP PA-RISC machines running HPUX. A preliminary
+version of this support was available as a set of patches from the
+University of Utah. GDB does not support debugging of programs
+compiled with the HP compiler, because HP will not document their file
+format. Instead, you must use GCC (version 2.3.2 or later) and PA-GAS
+(as available from jaguar.cs.utah.edu:/dist/pa-gas.u4.tar.Z).
+
+Many problems in the preliminary version have been fixed.
+
+ * Faster and better demangling
+
+We have improved template demangling and fixed numerous bugs in the GNU style
+demangler. It can now handle type modifiers such as `static' or `const'. Wide
+character types (wchar_t) are now supported. Demangling of each symbol is now
+only done once, and is cached when the symbol table for a file is read in.
+This results in a small increase in memory usage for C programs, a moderate
+increase in memory usage for C++ programs, and a fantastic speedup in
+symbol lookups.
- * New native hosts
+`Cfront' style demangling still doesn't work with AT&T cfront. It was written
+from the specifications in the Annotated Reference Manual, which AT&T's
+compiler does not actually implement.
-some 386 support
+ * G++ multiple inheritance compiler problem
- * New cross target hosts
+In the 2.3.2 release of gcc/g++, how the compiler resolves multiple
+inheritance lattices was reworked to properly discover ambiguities. We
+recently found an example which causes this new algorithm to fail in a
+very subtle way, producing bad debug information for those classes.
+The file 'gcc.patch' (in this directory) can be applied to gcc to
+circumvent the problem. A future GCC release will contain a complete
+fix.
-HP/Apollo 68k (under the BSD domain)
+The previous G++ debug info problem (mentioned below for the gdb-4.7
+release) is fixed in gcc version 2.3.2.
- * New cross targets
+ * Improved configure script
-Fujitsu SparcLite - This is a Sparc without floating-point intended for
-imbedded applications.
+The `configure' script will now attempt to guess your system type if
+you don't supply a host system type. The old scheme of supplying a
+host system triplet is preferable over using this. All the magic is
+done in the new `config.guess' script. Examine it for details.
- * G++/C++ support
+We have also brought our configure script much more in line with the FSF's
+version. It now supports the --with-xxx options. In particular,
+`--with-minimal-bfd' can be used to make the GDB binary image smaller.
+The resulting GDB will not be able to read arbitrary object file formats --
+only the format ``expected'' to be used on the configured target system.
+We hope to make this the default in a future release.
-As always, G++ support keeps on impoving. We now deal with Cfront style
-name mangling, and can even extract type info from mangled symbols.
+ * Documentation improvements
-Calling of virtual functions and inferior methods has been improved as well.
+There's new internal documentation on how to modify GDB, and how to
+produce clean changes to the code. We implore people to read it
+before submitting changes.
-GDB can now automatically figure out which symbol mangling style your C++
-compiler uses.
+The GDB manual uses new, sexy Texinfo conditionals, rather than arcane
+M4 macros. The new texinfo.tex is provided in this release. Pre-built
+`info' files are also provided. To build `info' files from scratch,
+you will need the latest `makeinfo' release, which will be available in
+a future texinfo-X.Y release.
+
+*NOTE* The new texinfo.tex can cause old versions of TeX to hang.
+We're not sure exactly which versions have this problem, but it has
+been seen in 3.0. We highly recommend upgrading to TeX version 3.141
+or better. If that isn't possible, there is a patch in
+`texinfo/tex3patch' that will modify `texinfo/texinfo.tex' to work
+around this problem.
+
+ * New features
+
+GDB now supports array constants that can be used in expressions typed in by
+the user. The syntax is `{element, element, ...}'. Ie: you can now type
+`print {1, 2, 3}', and it will build up an array in memory malloc'd in
+the target program.
+
+The new directory `gdb/sparclite' contains a program that demonstrates
+how the sparc-stub.c remote stub runs on a Fujitsu SPARClite processor.
+
+ * New native hosts supported
+
+HP/PA-RISC under HPUX using GNU tools hppa1.1-hp-hpux
+386 CPUs running SCO Unix 3.2v4 i386-unknown-sco3.2v4
+
+ * New targets supported
+
+AMD 29k family via UDI a29k-amd-udi or udi29k
+
+ * New file formats supported
+
+BFD now supports reading HP/PA-RISC executables (SOM file format?),
+HPUX core files, and SCO 3.2v2 core files.
* Major bug fixes
-The crash that was occuring when debugging Sun Ansi-C compiled binaries has
-been fixed. This was due mishandling of the extra SO stabs that the
-compiler was outputting.
-
-We also finally got Ultrix 4.2 up and running in house, and were able to
-really fix core file support!
-
-It was discovered that the reason that single-stepping was so slow on all
-of the Mips based platforms (primarily SGI and DEC) was that we were trying
-to demangle and lookup a symbol used for internal purposes on every instruction
-that was being stepped through. Changing the name of that symbol so that it
-couldn't be mistaken for a C++ mangled symbol sped things up a great deal.
-
-We also sped up symbol lookups in general by getting much smarter about
-when symbol mangling was necessary.
-
- * 29k support
-
-A bunch of work has been done to improve the general 29k support. In
-particular, a new user controllable variable 'call_scratch_address' can be
-used to specify the location of a scratch area to be used when GDB needs to
-call a function in the target. This was necessary because the usual method
-of putting the scratch area on the stack was not feasible for systems that
-have seperate instruction and data spaces.
-
-We also did a bunch of work on the 29k UDI (Universal Debugger Interface)
-code, but at the last minute we discovered that we didn't have all of the
-appropriate copyright paperwork, and had to yank it all out. We are working
-with AMD to resolve this, and hope to have it available soon.
-
- * Remote stuff
-
-We have made some improvements in the remote serial line protocol which should
-speed up things a great deal (especially for targets with lots of registers).
-The remote code now supports a new `expedited status' ('T') message which
-replaces the old 'S' status message. This message has a much more flexible
-format which allows the remote stub to send an arbitrary set of registers
-whenever the stub takes control. This greatly speeds up stepping, as the
-stub can supply only the registers GDB requires during this process. It
-eliminates the need to fetch the entire register set for each instruction being
-stepped through.
-
-GDB was also made a bit smarter about reading registers from the target. It
-now makes much more use of the cache. In effect, it now implements a
-write-through cache, and only reads the registers when if the target has run.
-
-There is also a new remote stub for Sparc processors. You can find it in
-gdb-4.7/gdb/sparc-stub.c. This was written to support the SparcLite product,
-but actually contains no SparcLite specific code. It should run on any
-stand-alone Sparc processor with a serial port that can be dedicated to GDB
-for remote debugging.
+Attaching to processes now works again; thanks for the many bug reports.
+
+We have also stomped on a bunch of core dumps caused by
+printf_filtered("%s") problems.
+
+We eliminated a copyright problem on the rpc and ptrace header files
+for VxWorks, which was discovered at the last minute during the 4.7
+release. You should now be able to build a VxWorks GDB.
+
+You can now interrupt gdb while an attached process is running. This
+will cause the attached process to stop, and give control back to GDB.
+
+We fixed problems caused by using too many file descriptors
+for reading symbols from object files and libraries. This was
+especially a problem for programs that used many (~100) shared
+libraries.
+
+The `step' command now only enters a subroutine if there is line number
+information for the subroutine. Otherwise it acts like the `next'
+command. Previously, `step' would enter subroutines if there was
+any debugging information about the routine. This avoids problems
+when using `cc -g1' on MIPS machines.
+
+ * Internal improvements
+
+GDB's internal interfaces have been improved to make it easier to support
+debugging of multiple languages in the future.
+
+GDB now uses a common structure for symbol information internally.
+Minimal symbols (derived from linkage symbols in object files), partial
+symbols (from a quick scan of debug information), and full symbols
+contain a common subset of information, making it easier to write
+shared code that handles any of them.
+
+ * New command line options
+
+We now accept --silent as an alias for --quiet.
+
+ * Mmalloc licensing
+
+The memory-mapped-malloc library is now licensed under the GNU Library
+General Public License.
+
+*** Changes in GDB-4.7:
* Host/native/target split
-GDB has had some major internal surgery recently in order to untangle some
-of the mess related to supporting hosts and remote targets. Now, when you
-configure GDB for a remote target, it may no longer load in all of the host
-support for debugging local programs. This means that if you make a GDB to
-debug a remote vxWorks target from a Sun4 host, you will no longer get
-ptrace() or Sun4 core file support. This surgery was necessary to ensure
-that arbitrary host/target combinations were possible. In particular, it
-makes it much more practical to build new configurations for remote targets
-that in the past were only hosts.
-
-The primary concept behind the detanglement was to seperate the code into
-one of three categories. The host category is for code that is host
-specific, and can only be compiled for a particular host configuration.
-The target category is for code which is target specific, but can be
-compiled on any host. The native category is for the situation where the
-host and target are the same system (this usually means that you are going
-to debug an inferior process).
-
- * General
-
-There is a new opcodes library which will contain all of the disassembly
-routines, and opcode tables at some point in the future. At present, it
-only contains Sparc and Z8000 routines. This was done in order to get the
-assembler and the debugger to share these routines.
-
-The file gdb-4.7/gdb/doc/stabs.texinfo is a (relatively) complete reference
-to the stabs symbol info used by the debugger. It is (as far as we know)
-the only published document on this fascinating topic.
-
-There are now pre-command hooks that are used to attach arbitrary commands
-to any command. The commands in the hook will be executed prior to the
-users command. You can creat a hook which will be executed whenever the
-program stops.
-
-BFD now supports the Zilog Z8000 microprocessor.
+GDB has had some major internal surgery to untangle the support for
+hosts and remote targets. Now, when you configure GDB for a remote
+target, it will no longer load in all of the support for debugging
+local programs on the host. When fully completed and tested, this will
+ensure that arbitrary host/target combinations are possible.
+
+The primary conceptual shift is to separate the non-portable code in
+GDB into three categories. Host specific code is required any time GDB
+is compiled on that host, regardless of the target. Target specific
+code relates to the peculiarities of the target, but can be compiled on
+any host. Native specific code is everything else: it can only be
+built when the host and target are the same system. Child process
+handling and core file support are two common `native' examples.
+
+GDB's use of /proc for controlling Unix child processes is now cleaner.
+It has been split out into a single module under the `target_ops' vector,
+plus two native-dependent functions for each system that uses /proc.
+
+ * New hosts supported
+
+HP/Apollo 68k (under the BSD domain) m68k-apollo-bsd or apollo68bsd
+386 CPUs running various BSD ports i386-unknown-bsd or 386bsd
+386 CPUs running SCO Unix i386-unknown-scosysv322 or i386sco
+
+ * New targets supported
+
+Fujitsu SPARClite sparclite-fujitsu-none or sparclite
+68030 and CPU32 m68030-*-*, m68332-*-*
+
+ * New native hosts supported
+
+386 CPUs running various BSD ports i386-unknown-bsd or 386bsd
+ (386bsd is not well tested yet)
+386 CPUs running SCO Unix i386-unknown-scosysv322 or sco
+
+ * New file formats supported
+
+BFD now supports COFF files for the Zilog Z8000 microprocessor. It
+supports reading of `a.out.adobe' object files, which are an a.out
+format extended with minimal information about multiple sections.
+
+ * New commands
+
+`show copying' is the same as the old `info copying'.
+`show warranty' is the same as `info warrantee'.
+These were renamed for consistency. The old commands continue to work.
+
+`info handle' is a new alias for `info signals'.
+
+You can now define pre-command hooks, which attach arbitrary command
+scripts to any command. The commands in the hook will be executed
+prior to the user's command. You can also create a hook which will be
+executed whenever the program stops. See gdb.texinfo.
+
+ * C++ improvements
+
+We now deal with Cfront style name mangling, and can even extract type
+info from mangled symbols. GDB can automatically figure out which
+symbol mangling style your C++ compiler uses.
+
+Calling of methods and virtual functions has been improved as well.
+
+ * Major bug fixes
+
+The crash that occured when debugging Sun Ansi-C compiled binaries is
+fixed. This was due to mishandling of the extra N_SO stabs output
+by the compiler.
+
+We also finally got Ultrix 4.2 running in house, and fixed core file
+support, with help from a dozen people on the net.
+
+John M. Farrell discovered that the reason that single-stepping was so
+slow on all of the Mips based platforms (primarily SGI and DEC) was
+that we were trying to demangle and lookup a symbol used for internal
+purposes on every instruction that was being stepped through. Changing
+the name of that symbol so that it couldn't be mistaken for a C++
+mangled symbol sped things up a great deal.
+
+Rich Pixley sped up symbol lookups in general by getting much smarter
+about when C++ symbol mangling is necessary. This should make symbol
+completion (TAB on the command line) much faster. It's not as fast as
+we'd like, but it's significantly faster than gdb-4.6.
+
+ * AMD 29k support
+
+A new user controllable variable 'call_scratch_address' can
+specify the location of a scratch area to be used when GDB
+calls a function in the target. This is necessary because the
+usual method of putting the scratch area on the stack does not work
+in systems that have separate instruction and data spaces.
+
+We integrated changes to support the 29k UDI (Universal Debugger
+Interface), but discovered at the last minute that we didn't have all
+of the appropriate copyright paperwork. We are working with AMD to
+resolve this, and hope to have it available soon.
+
+ * Remote interfaces
+
+We have sped up the remote serial line protocol, especially for targets
+with lots of registers. It now supports a new `expedited status' ('T')
+message which can be used in place of the existing 'S' status message.
+This allows the remote stub to send only the registers that GDB
+needs to make a quick decision about single-stepping or conditional
+breakpoints, eliminating the need to fetch the entire register set for
+each instruction being stepped through.
+
+The GDB remote serial protocol now implements a write-through cache for
+registers, only re-reading the registers if the target has run.
+
+There is also a new remote serial stub for SPARC processors. You can
+find it in gdb-4.7/gdb/sparc-stub.c. This was written to support the
+Fujitsu SPARClite processor, but will run on any stand-alone SPARC
+processor with a serial port.
+
+ * Configuration
+
+Configure.in files have become much easier to read and modify. A new
+`table driven' format makes it more obvious what configurations are
+supported, and what files each one uses.
+
+ * Library changes
+
+There is a new opcodes library which will eventually contain all of the
+disassembly routines and opcode tables. At present, it only contains
+Sparc and Z8000 routines. This will allow the assembler, debugger, and
+disassembler (binutils/objdump) to share these routines.
+
+The libiberty library is now copylefted under the GNU Library General
+Public License. This allows more liberal use, and was done so libg++
+can use it. This makes no difference to GDB, since the Library License
+grants all the rights from the General Public License.
+
+ * Documentation
+
+The file gdb-4.7/gdb/doc/stabs.texinfo is a (relatively) complete
+reference to the stabs symbol info used by the debugger. It is (as far
+as we know) the only published document on this fascinating topic. We
+encourage you to read it, compare it to the stabs information on your
+system, and send improvements on the document in general (to
+bug-gdb@prep.ai.mit.edu).
And, of course, many bugs have been fixed.
+
*** Changes in GDB-4.6:
* Better support for C++ function names