binutils-gdb/gdb/NEWS

		What has changed since GDB-3.5?
		(Organized release by release)

*** Changes in GDB-4.7:

 * New native hosts

some 386 support

 * New cross target hosts

HP/Apollo 68k (under the BSD domain)

 * New cross targets

Fujitsu SparcLite - This is a Sparc without floating-point intended for
imbedded applications.

 * G++/C++ support

As always, G++ support keeps on impoving.  We now deal with Cfront style
name mangling, and can even extract type info from mangled symbols.

Calling of virtual functions and inferior methods has been improved as well.

GDB can now automatically figure out which symbol mangling style your C++
compiler uses.

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

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

And, of course, many bugs have been fixed.

*** Changes in GDB-4.6:

 * Better support for C++ function names

GDB now accepts as input the "demangled form" of C++ overloaded function
names and member function names, and can do command completion on such names
(using TAB, TAB-TAB, and ESC-?).  The names have to be quoted with a pair of
single quotes.  Examples are 'func (int, long)' and 'obj::operator==(obj&)'.
Make use of command completion, it is your friend.

GDB also now accepts a variety of C++ mangled symbol formats.  They are
the GNU g++ style, the Cfront (ARM) style, and the Lucid (lcc) style.
You can tell GDB which format to use by doing a 'set demangle-style {gnu,
lucid, cfront, auto}'.  'gnu' is the default.  Do a 'set demangle-style foo'
for the list of formats.

 * G++ symbol mangling problem

Recent versions of gcc have a bug in how they emit debugging information for
C++ methods (when using dbx-style stabs).  The file 'gcc.patch' (in this
directory) can be applied to gcc to fix the problem.  Alternatively, if you
can't fix gcc, you can #define GCC_MANGLE_BUG when compling gdb/symtab.c. The
usual symptom is difficulty with setting breakpoints on methods.  GDB complains
about the method being non-existent.  (We believe that version 2.2.2 of GCC has
this problem.)

 * New 'maintenance' command

All of the commands related to hacking GDB internals have been moved out of
the main command set, and now live behind the 'maintenance' command.  This
can also be abbreviated as 'mt'.  The following changes were made:

	dump-me ->		maintenance dump-me
	info all-breakpoints ->	maintenance info breakpoints
	printmsyms ->		maintenance print msyms
	printobjfiles ->	maintenance print objfiles
	printpsyms ->		maintenance print psymbols
	printsyms ->		maintenance print symbols

The following commands are new:

	maintenance demangle	Call internal GDB demangler routine to
				demangle a C++ link name and prints the result.
	maintenance print type	Print a type chain for a given symbol

 * Change to .gdbinit file processing

We now read the $HOME/.gdbinit file before processing the argv arguments
(e.g. reading symbol files or core files).  This allows global parameters to
be set, which will apply during the symbol reading.  The ./.gdbinit is still
read after argv processing.

 * New hosts supported

Solaris-2.0 !!!				sparc-sun-solaris2  or  sun4sol2

Linux support				i386-unknown-linux  or  linux

We are also including code to support the HP/PA running BSD and HPUX.  This
is almost guaranteed not to work, as we didn't have time to test or build it
for this release.  We are including it so that the more adventurous (or
masochistic) of you can play with it.  We also had major problems with the
fact that the compiler that we got from HP doesn't support the -g option.
It costs extra.

 * New targets supported

Hitachi H8/300				h8300-hitachi-hms  or  h8300hms

 * More smarts about finding #include files

GDB now remembers the compilation directory for all include files, and for
all files from which C is generated (like yacc and lex sources).  This
greatly improves GDB's ability to find yacc/lex sources, and include files,
especially if you are debugging your program from a directory different from
the one that contains your sources.

We also fixed a bug which caused difficulty with listing and setting
breakpoints in include files which contain C code.  (In the past, you had to
try twice in order to list an include file that you hadn't looked at before.)

 * Interesting infernals change

GDB now deals with arbitrary numbers of sections, where the symbols for each
section must be relocated relative to that section's landing place in the
target's address space.  This work was needed to support ELF with embedded
stabs used by Solaris-2.0.

 * Bug fixes (of course!)

There have been loads of fixes for the following things:
	mips, rs6000, 29k/udi, m68k, g++, type handling, elf/dwarf, m88k,
	i960, stabs, DOS(GO32), procfs, etc...

See the ChangeLog for details.

*** Changes in GDB-4.5:

 * New machines supported (host and target)

IBM RS6000 running AIX			rs6000-ibm-aix	or rs6000

SGI Irix-4.x				mips-sgi-irix4	or iris4

 * New malloc package

GDB now uses a new memory manager called mmalloc, based on gmalloc.
Mmalloc is capable of handling mutiple heaps of memory.  It is also
capable of saving a heap to a file, and then mapping it back in later.
This can be used to greatly speedup the startup of GDB by using a
pre-parsed symbol table which lives in a mmalloc managed heap.  For
more details, please read mmalloc/mmalloc.texi.

 * info proc

The 'info proc' command (SVR4 only) has been enhanced quite a bit.  See
'help info proc' for details.

 * MIPS ecoff symbol table format

The code that reads MIPS symbol table format is now supported on all hosts.
Thanks to MIPS for releasing the sym.h and symconst.h files to make this
possible.

 * File name changes for MS-DOS

Many files in the config directories have been renamed to make it easier to
support GDB on MS-DOSe systems (which have very restrictive file name
conventions :-( ).  MS-DOSe host support (under DJ Delorie's GO32
environment) is close to working but has some remaining problems.  Note
that debugging of DOS programs is not supported, due to limitations
in the ``operating system'', but it can be used to host cross-debugging.

 * Cross byte order fixes

Many fixes have been made to support cross debugging of Sparc and MIPS
targets from hosts whose byte order differs.

 * New -mapped and -readnow options

If memory-mapped files are available on your system through the 'mmap'
system call, you can use the -mapped option on the `file' or
`symbol-file' commands to cause GDB to write the symbols from your
program into a reusable file.  If the program you are debugging is
called `/path/fred', the mapped symbol file will be `./fred.syms'.
Future GDB debugging sessions will notice the presence of this file,
and will quickly map in symbol information from it, rather than reading
the symbol table from the executable program.  Using the '-mapped'
option in a GDB `file' or `symbol-file' command has the same effect as
starting GDB with the '-mapped' command-line option.

You can cause GDB to read the entire symbol table immediately by using
the '-readnow' option with any of the commands that load symbol table
information (or on the GDB command line).  This makes the command
slower, but makes future operations faster.

The -mapped and -readnow options are typically combined in order to
build a `fred.syms' file that contains complete symbol information.
A simple GDB invocation to do nothing but build a `.syms' file for future
use is:

	gdb -batch -nx -mapped -readnow programname

The `.syms' file is specific to the host machine on which GDB is run.
It holds an exact image of GDB's internal symbol table.  It cannot be
shared across multiple host platforms.

 * longjmp() handling

GDB is now capable of stepping and nexting over longjmp(), _longjmp(), and
siglongjmp() without losing control.  This feature has not yet been ported to
all systems.  It currently works on many 386 platforms, all MIPS-based
platforms (SGI, DECstation, etc), and Sun3/4.

 * Solaris 2.0

Preliminary work has been put in to support the new Solaris OS from Sun.  At
this time, it can control and debug processes, but it is not capable of
reading symbols.

 * Bug fixes

As always, many many bug fixes.  The major areas were with g++, and mipsread.
People using the MIPS-based platforms should experience fewer mysterious
crashes and trashed symbol tables.

*** Changes in GDB-4.4:

 * New machines supported (host and target)

SCO Unix on i386 IBM PC clones		i386-sco-sysv	or  i386sco
	(except core files)
BSD Reno on Vax				vax-dec-bsd
Ultrix on Vax				vax-dec-ultrix

 * New machines supported (target)

AMD 29000 embedded, using EBMON		a29k-none-none

 * C++ support

GDB continues to improve its handling of C++.  `References' work better.
The demangler has also been improved, and now deals with symbols mangled as
per the Annotated C++ Reference Guide.

GDB also now handles `stabs' symbol information embedded in MIPS
`ecoff' symbol tables.  Since the ecoff format was not easily
extensible to handle new languages such as C++, this appeared to be a
good way to put C++ debugging info into MIPS binaries.  This option
will be supported in the GNU C compiler, version 2, when it is
released.

 * New features for SVR4

GDB now handles SVR4 shared libraries, in the same fashion as SunOS
shared libraries.  Debugging dynamically linked programs should present
only minor differences from debugging statically linked programs.

The `info proc' command will print out information about any process
on an SVR4 system (including the one you are debugging).  At the moment,
it prints the address mappings of the process.

If you bring up GDB on another SVR4 system, please send mail to
bug-gdb@prep.ai.mit.edu to let us know what changes were reqired (if any).

 * Better dynamic linking support in SunOS

Reading symbols from shared libraries which contain debugging symbols
now works properly.  However, there remain issues such as automatic
skipping of `transfer vector' code during function calls, which
make it harder to debug code in a shared library, than to debug the
same code linked statically.

 * New Getopt

GDB is now using the latest `getopt' routines from the FSF.  This
version accepts the -- prefix for options with long names.  GDB will
continue to accept the old forms (-option and +option) as well.
Various single letter abbreviations for options have been explicity
added to the option table so that they won't get overshadowed in the
future by other options that begin with the same letter.

 * Bugs fixed

The `cleanup_undefined_types' bug that many of you noticed has been squashed.
Many assorted bugs have been handled.  Many more remain to be handled.
See the various ChangeLog files (primarily in gdb and bfd) for details.


*** Changes in GDB-4.3:

 * New machines supported (host and target)

Amiga 3000 running Amix			m68k-cbm-svr4	or  amix
NCR 3000 386 running SVR4		i386-ncr-svr4	or  ncr3000
Motorola Delta 88000 running Sys V	m88k-motorola-sysv  or  delta88

 * Almost SCO Unix support

We had hoped to support:
SCO Unix on i386 IBM PC clones		i386-sco-sysv	or  i386sco
(except for core file support), but we discovered very late in the release
that it has problems with process groups that render gdb unusable.  Sorry
about that.  I encourage people to fix it and post the fixes.

 * Preliminary ELF and DWARF support

GDB can read ELF object files on System V Release 4, and can handle
debugging records for C, in DWARF format, in ELF files.  This support
is preliminary.  If you bring up GDB on another SVR4 system, please
send mail to bug-gdb@prep.ai.mit.edu to let us know what changes were
reqired (if any).

 * New Readline

GDB now uses the latest `readline' library.  One user-visible change
is that two tabs will list possible command completions, which previously
required typing M-? (meta-question mark, or ESC ?).

 * Bugs fixed

The `stepi' bug that many of you noticed has been squashed.
Many bugs in C++ have been handled.  Many more remain to be handled.
See the various ChangeLog files (primarily in gdb and bfd) for details.

 * State of the MIPS world (in case you wondered):

GDB can understand the symbol tables emitted by the compilers
supplied by most vendors of MIPS-based machines, including DEC.  These
symbol tables are in a format that essentially nobody else uses.

Some versions of gcc come with an assembler post-processor called
mips-tfile.  This program is required if you want to do source-level
debugging of gcc-compiled programs.  I believe FSF does not ship
mips-tfile with gcc version 1, but it will eventually come with gcc
version 2.

Debugging of g++ output remains a problem.  g++ version 1.xx does not
really support it at all.  (If you're lucky, you should be able to get
line numbers and stack traces to work, but no parameters or local
variables.)  With some work it should be possible to improve the
situation somewhat.

When gcc version 2 is released, you will have somewhat better luck.
However, even then you will get confusing results for inheritance and
methods.

We will eventually provide full debugging of g++ output on
DECstations.  This will probably involve some kind of stabs-in-ecoff
encapulation, but the details have not been worked out yet.


*** Changes in GDB-4.2:

 *  Improved configuration

Only one copy of `configure' exists now, and it is not self-modifying.
Porting BFD is simpler.  

 *  Stepping improved

The `step' and `next' commands now only stop at the first instruction
of a source line.  This prevents the multiple stops that used to occur
in switch statements, for-loops, etc.  `Step' continues to stop if a
function that has debugging information is called within the line.

 *  Bug fixing

Lots of small bugs fixed.  More remain.

 *  New host supported (not target)

Intel 386 PC clone running Mach		i386-none-mach


*** Changes in GDB-4.1:

 *  Multiple source language support

GDB now has internal scaffolding to handle several source languages.
It determines the type of each source file from its filename extension,
and will switch expression parsing and number formatting to match the
language of the function in the currently selected stack frame.
You can also specifically set the language to be used, with
`set language c' or `set language modula-2'.

 *  GDB and Modula-2

GDB now has preliminary support for the GNU Modula-2 compiler,
currently under development at the State University of New York at
Buffalo.  Development of both GDB and the GNU Modula-2 compiler will
continue through the fall of 1991 and into 1992.

Other Modula-2 compilers are currently not supported, and attempting to
debug programs compiled with them will likely result in an error as the
symbol table is read.  Feel free to work on it, though!

There are hooks in GDB for strict type checking and range checking,
in the `Modula-2 philosophy', but they do not currently work.

 * set write on/off

GDB can now write to executable and core files (e.g. patch
a variable's value).   You must turn this switch on, specify
the file ("exec foo" or "core foo"), *then* modify it, e.g.
by assigning a new value to a variable.  Modifications take
effect immediately.

 * Automatic SunOS shared library reading

When you run your program, GDB automatically determines where its
shared libraries (if any) have been loaded, and reads their symbols.
The `share' command is no longer needed.  This also works when
examining core files.

 * set listsize

You can specify the number of lines that the `list' command shows.
The default is 10.

 * New machines supported (host and target)

SGI Iris (MIPS) running Irix V3:  	mips-sgi-irix   or  iris
Sony NEWS (68K) running NEWSOS 3.x:	m68k-sony-sysv	or  news
Ultracomputer (29K) running Sym1:	a29k-nyu-sym1	or  ultra3

 * New hosts supported (not targets)

IBM RT/PC:				romp-ibm-aix 	or  rtpc

 * New targets supported (not hosts)

AMD 29000 embedded with COFF		a29k-none-coff
AMD 29000 embedded with a.out		a29k-none-aout
Ultracomputer remote kernel debug	a29k-nyu-kern

 * New remote interfaces

AMD 29000 Adapt
AMD 29000 Minimon


*** Changes in GDB-4.0:

 *  New Facilities

Wide output is wrapped at good places to make the output more readable.

Gdb now supports cross-debugging from a host machine of one type to a
target machine of another type.  Communication with the target system
is over serial lines.  The ``target'' command handles connecting to the
remote system; the ``load'' command will download a program into the
remote system.  Serial stubs for the m68k and i386 are provided.  Gdb
also supports debugging of realtime processes running under VxWorks,
using SunRPC Remote Procedure Calls over TCP/IP to talk to a debugger
stub on the target system.

New CPUs supported include the AMD 29000 and Intel 960.

GDB now reads object files and symbol tables via a ``binary file'' 
library, which allows a single copy of GDB to debug programs of multiple
object file types such as a.out and coff.

There is now a GDB reference card in "doc/refcard.tex".  (Make targets
refcard.dvi and refcard.ps are available to format it).


 *  Control-Variable user interface simplified

All variables that control the operation of the debugger can be set
by the ``set'' command, and displayed by the ``show'' command.

For example, ``set prompt new-gdb=>'' will change your prompt to new-gdb=>.
``Show prompt'' produces the response:
Gdb's prompt is new-gdb=>.

What follows are the NEW set commands.  The command ``help set'' will
print a complete list of old and new set commands.  ``help set FOO''
will give a longer description of the variable FOO.  ``show'' will show
all of the variable descriptions and their current settings.

confirm on/off:  Enables warning questions for operations that are
		 hard to recover from, e.g. rerunning the program while
		 it is already running.  Default is ON.

editing on/off:  Enables EMACS style command line editing 
                 of input.  Previous lines can be recalled with 
		 control-P, the current line can be edited with control-B,
		 you can search for commands with control-R, etc.
		 Default is ON.

history filename NAME:  NAME is where the gdb command history 
			will be stored.  The default is .gdb_history,
			or the value of the environment variable
			GDBHISTFILE.

history size N:  The size, in commands, of the command history.  The 
		 default is 256, or the value of the environment variable
		 HISTSIZE.

history save on/off: If this value is set to ON, the history file will
		      be saved after exiting gdb.  If set to OFF, the 
		      file will not be saved.  The default is OFF.

history expansion on/off: If this value is set to ON, then csh-like 
			  history expansion will be performed  on 
			  command line input.  The default is OFF.

radix N:  Sets the default radix for input and output.  It can be set
	  to 8, 10, or 16.  Note that the argument to "radix" is interpreted
	  in the current radix, so "set radix 10" is always a no-op.

height N: This integer value is the number of lines on a page. Default
          is 24, the current `stty rows'' setting, or the ``li#''
	  setting from the termcap entry matching the environment
	  variable TERM.

width N:  This integer value is the number of characters on a line.
	  Default is 80, the current `stty cols'' setting, or the ``co#''
	  setting from the termcap entry matching the environment
	  variable TERM.

Note: ``set screensize'' is obsolete. Use ``set height'' and
``set width'' instead.

print address on/off:  Print memory addresses in various command displays,
		      such as stack traces and structure values.  Gdb looks
		      more ``symbolic'' if you turn this off; it looks more
		      ``machine level'' with it on.  Default is ON.

print array on/off:  Prettyprint arrays.  New convenient format!  Default 
                    is OFF.

print demangle on/off:   Print C++ symbols in "source" form if on,
			"raw" form if off.

print asm-demangle on/off:  Same, for assembler level printouts
			like instructions.

print vtbl on/off:  Prettyprint C++ virtual function tables.  Default is OFF.


 *  Support for Epoch Environment.

The epoch environment is a version of Emacs v18 with windowing.  One
new command, ``inspect'', is identical to ``print'', except that if you
are running in the epoch environment, the value is printed in its own
window.


 *  Support for Shared Libraries

GDB can now debug programs and core files that use SunOS shared libraries.
Symbols from a shared library cannot be referenced
before the shared library has been linked with the program (this
happens after you type ``run'' and before the function main() is entered).
At any time after this linking (including when examining core files
from dynamically linked programs), gdb reads the symbols from each
shared library when you type the ``sharedlibrary'' command.
It can be abbreviated ``share''.

sharedlibrary REGEXP:  Load shared object library symbols for files 
                       matching a unix regular expression.  No argument
		       indicates to load symbols for all shared libraries.

info sharedlibrary:  Status of loaded shared libraries.


 *  Watchpoints

A watchpoint stops execution of a program whenever the value of an
expression changes.  Checking for this slows down execution
tremendously whenever you are in the scope of the expression, but is
quite useful for catching tough ``bit-spreader'' or pointer misuse
problems.  Some machines such as the 386 have hardware for doing this
more quickly, and future versions of gdb will use this hardware.

watch EXP:  Set a watchpoint (breakpoint) for an expression.

info watchpoints:  Information about your watchpoints.

delete N:   Deletes watchpoint number N (same as breakpoints).
disable N:  Temporarily turns off watchpoint number N (same as breakpoints).
enable N:   Re-enables watchpoint number N (same as breakpoints).


 *  C++ multiple inheritance

When used with a GCC version 2 compiler, GDB supports multiple inheritance
for C++ programs.

 *  C++ exception handling

Gdb now supports limited C++ exception handling.  Besides the existing
ability to breakpoint on an exception handler, gdb can breakpoint on
the raising of an exception (before the stack is peeled back to the
handler's context).

catch FOO:  If there is a FOO exception handler in the dynamic scope,
	    set a breakpoint to catch exceptions which may be raised there.
	    Multiple exceptions (``catch foo bar baz'') may be caught.

info catch:  Lists all exceptions which may be caught in the
             current stack frame.


 *  Minor command changes

The command ``call func (arg, arg, ...)'' now acts like the print
command, except it does not print or save a value if the function's result
is void.  This is similar to dbx usage.

The ``up'' and ``down'' commands now always print the frame they end up
at; ``up-silently'' and `down-silently'' can be used in scripts to change
frames without printing.

 *  New directory command

'dir' now adds directories to the FRONT of the source search path.
The path starts off empty.  Source files that contain debug information
about the directory in which they were compiled can be found even
with an empty path; Sun CC and GCC include this information.  If GDB can't
find your source file in the current directory, type "dir .".

 * Configuring GDB for compilation

For normal use, type ``./configure host''.  See README or gdb.texinfo
for more details.

GDB now handles cross debugging.  If you are remotely debugging between 
two different machines, type ``./configure host -target=targ''.
Host is the machine where GDB will run; targ is the machine
where the program that you are debugging will run.