news

早期freebsd实现

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

*** Changes in GDB-4.7:

 * Host/native/target split

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
[e-mail]).

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.