More news...
This commit is contained in:
parent
ebb16da17d
commit
c00d8242d4
199
gdb/NEWS
199
gdb/NEWS
|
@ -3,123 +3,152 @@
|
||||||
|
|
||||||
*** Changes in GDB-4.7:
|
*** Changes in GDB-4.7:
|
||||||
|
|
||||||
* New native hosts
|
* Host/native/target split
|
||||||
|
|
||||||
some 386 support
|
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.
|
||||||
|
|
||||||
* New cross target hosts
|
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.
|
||||||
|
|
||||||
HP/Apollo 68k (under the BSD domain)
|
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 cross targets
|
* New hosts supported
|
||||||
|
|
||||||
Fujitsu SparcLite - This is a Sparc without floating-point intended for
|
HP/Apollo 68k (under the BSD domain) m68k-apollo-bsd or apollo68bsd
|
||||||
imbedded applications.
|
386 CPUs running various BSD ports i386-unknown-bsd or 386bsd
|
||||||
|
386 CPUs running SCO Unix i386-unknown-scosysv322 or i386sco
|
||||||
|
|
||||||
* G++/C++ support
|
* New targets supported
|
||||||
|
|
||||||
As always, G++ support keeps on impoving. We now deal with Cfront style
|
Fujitsu SPARClite sparclite-fujitsu-none or sparclite
|
||||||
name mangling, and can even extract type info from mangled symbols.
|
68030 and CPU32 m68030-*-*, m68332-*-*
|
||||||
|
|
||||||
Calling of virtual functions and inferior methods has been improved as well.
|
* New native hosts supported
|
||||||
|
|
||||||
GDB can now automatically figure out which symbol mangling style your C++
|
386 CPUs running various BSD ports i386-unknown-bsd or 386bsd
|
||||||
compiler uses.
|
(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
|
* Major bug fixes
|
||||||
|
|
||||||
The crash that was occuring when debugging Sun Ansi-C compiled binaries has
|
The crash that occured when debugging Sun Ansi-C compiled binaries is
|
||||||
been fixed. This was due mishandling of the extra SO stabs that the
|
fixed. This was due to mishandling of the extra N_SO stabs output
|
||||||
compiler was outputting.
|
by the compiler.
|
||||||
|
|
||||||
We also finally got Ultrix 4.2 up and running in house, and were able to
|
We also finally got Ultrix 4.2 running in house, and fixed core file
|
||||||
really fix core file support!
|
support, with help from a dozen people on the net.
|
||||||
|
|
||||||
It was discovered that the reason that single-stepping was so slow on all
|
John M. Farrell discovered that the reason that single-stepping was so
|
||||||
of the Mips based platforms (primarily SGI and DEC) was that we were trying
|
slow on all of the Mips based platforms (primarily SGI and DEC) was
|
||||||
to demangle and lookup a symbol used for internal purposes on every instruction
|
that we were trying to demangle and lookup a symbol used for internal
|
||||||
that was being stepped through. Changing the name of that symbol so that it
|
purposes on every instruction that was being stepped through. Changing
|
||||||
couldn't be mistaken for a C++ mangled symbol sped things up a great deal.
|
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
|
Rich Pixley sped up symbol lookups in general by getting much smarter
|
||||||
when symbol mangling was necessary.
|
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.
|
||||||
|
|
||||||
* 29k support
|
* AMD 29k support
|
||||||
|
|
||||||
A bunch of work has been done to improve the general 29k support. In
|
A new user controllable variable 'call_scratch_address' can
|
||||||
particular, a new user controllable variable 'call_scratch_address' can be
|
specify the location of a scratch area to be used when GDB
|
||||||
used to specify the location of a scratch area to be used when GDB needs to
|
calls a function in the target. This is necessary because the
|
||||||
call a function in the target. This was necessary because the usual method
|
usual method of putting the scratch area on the stack does not work
|
||||||
of putting the scratch area on the stack was not feasible for systems that
|
in systems that have separate instruction and data spaces.
|
||||||
have seperate instruction and data spaces.
|
|
||||||
|
|
||||||
We also did a bunch of work on the 29k UDI (Universal Debugger Interface)
|
We integrated changes to support the 29k UDI (Universal Debugger
|
||||||
code, but at the last minute we discovered that we didn't have all of the
|
Interface), but discovered at the last minute that we didn't have all
|
||||||
appropriate copyright paperwork, and had to yank it all out. We are working
|
of the appropriate copyright paperwork. We are working with AMD to
|
||||||
with AMD to resolve this, and hope to have it available soon.
|
resolve this, and hope to have it available soon.
|
||||||
|
|
||||||
* Remote stuff
|
* Remote interfaces
|
||||||
|
|
||||||
We have made some improvements in the remote serial line protocol which should
|
We have sped up the remote serial line protocol, especially for targets
|
||||||
speed up things a great deal (especially for targets with lots of registers).
|
with lots of registers. It now supports a new `expedited status' ('T')
|
||||||
The remote code now supports a new `expedited status' ('T') message which
|
message which can be used in place of the existing 'S' status message.
|
||||||
replaces the old 'S' status message. This message has a much more flexible
|
This allows the remote stub to send only the registers that GDB
|
||||||
format which allows the remote stub to send an arbitrary set of registers
|
needs to make a quick decision about single-stepping or conditional
|
||||||
whenever the stub takes control. This greatly speeds up stepping, as the
|
breakpoints, eliminating the need to fetch the entire register set for
|
||||||
stub can supply only the registers GDB requires during this process. It
|
each instruction being stepped through.
|
||||||
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
|
The GDB remote serial protocol now implements a write-through cache for
|
||||||
now makes much more use of the cache. In effect, it now implements a
|
registers, only re-reading the registers if the target has run.
|
||||||
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
|
There is also a new remote serial stub for SPARC processors. You can
|
||||||
gdb-4.7/gdb/sparc-stub.c. This was written to support the SparcLite product,
|
find it in gdb-4.7/gdb/sparc-stub.c. This was written to support the
|
||||||
but actually contains no SparcLite specific code. It should run on any
|
Fujitsu SPARClite processor, but will run on any stand-alone SPARC
|
||||||
stand-alone Sparc processor with a serial port that can be dedicated to GDB
|
processor with a serial port.
|
||||||
for remote debugging.
|
|
||||||
|
|
||||||
* Host/native/target split
|
* Configuration
|
||||||
|
|
||||||
GDB has had some major internal surgery recently in order to untangle some
|
Configure.in files have become much easier to read and modify. A new
|
||||||
of the mess related to supporting hosts and remote targets. Now, when you
|
`table driven' format makes it more obvious what configurations are
|
||||||
configure GDB for a remote target, it may no longer load in all of the host
|
supported, and what files each one uses.
|
||||||
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
|
* Library changes
|
||||||
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 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.
|
||||||
|
|
||||||
There is a new opcodes library which will contain all of the disassembly
|
The libiberty library is now copylefted under the GNU Library General
|
||||||
routines, and opcode tables at some point in the future. At present, it
|
Public License. This allows more liberal use, and was done so libg++
|
||||||
only contains Sparc and Z8000 routines. This was done in order to get the
|
can use it. This makes no difference to GDB, since the Library License
|
||||||
assembler and the debugger to share these routines.
|
grants all the rights from the General Public License.
|
||||||
|
|
||||||
The file gdb-4.7/gdb/doc/stabs.texinfo is a (relatively) complete reference
|
* Documentation
|
||||||
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
|
The file gdb-4.7/gdb/doc/stabs.texinfo is a (relatively) complete
|
||||||
to any command. The commands in the hook will be executed prior to the
|
reference to the stabs symbol info used by the debugger. It is (as far
|
||||||
users command. You can creat a hook which will be executed whenever the
|
as we know) the only published document on this fascinating topic. We
|
||||||
program stops.
|
encourage you to read it, compare it to the stabs information on your
|
||||||
|
system, and send improvements on the document in general (to
|
||||||
BFD now supports the Zilog Z8000 microprocessor.
|
bug-gdb@prep.ai.mit.edu).
|
||||||
|
|
||||||
And, of course, many bugs have been fixed.
|
And, of course, many bugs have been fixed.
|
||||||
|
|
||||||
|
|
||||||
*** Changes in GDB-4.6:
|
*** Changes in GDB-4.6:
|
||||||
|
|
||||||
* Better support for C++ function names
|
* Better support for C++ function names
|
||||||
|
|
Loading…
Reference in New Issue