OpenE2K
/
binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

More news...

This commit is contained in:
John Gilmore 1992-10-23 10:38:16 +00:00
parent ebb16da17d
commit c00d8242d4
1 changed files with 114 additions and 85 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

199
gdb/NEWS
View File

@ -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