This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
[rfc/5.1] README clean out
- To: gdb-patches at sources dot redhat dot com
- Subject: [rfc/5.1] README clean out
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 25 Jul 2001 22:50:05 -0400
Hello,
The attatched patch cleans out the README file. Of the sections being
removed, the one I'm not sure on is ``Remote debugging''. I think
removing the others is a good move :-)
The new section ``Host/target specific installation notes'' currently
contains a hint for the SPARC maintainer - I think it should at least
mention how to build a sparc64 GDB. Hmm, perhaphs DJGPP specific notes
should also live here as well.
enjoy,
Andrew
2001-07-25 Andrew Cagney <ac131313@redhat.com>
* README (Known bugs): Delete section.
(Kernel debugging): Delete section.
(Remote debugging): Delete section.
(Languages other than C): Delete section.
(Host/target specific installation notes) New section.
Index: README
===================================================================
RCS file: /cvs/src/src/gdb/README,v
retrieving revision 1.7
diff -p -r1.7 README
*** README 2001/07/25 14:58:38 1.7
--- README 2001/07/26 02:44:16
*************** other GNU tools recursively; but these a
*** 426,496 ****
GDB or its supporting libraries.
! Languages other than C
! =======================
! See the GDB manual (gdb/doc/gdb.texinfo) for information on this.
- Kernel debugging
- =================
- Remote debugging over serial lines works fine, but the kernel
- debugging code in here has not been tested in years. Van Jacobson has
- better kernel debugging, but the UC lawyers won't let FSF have it.
-
-
- Remote debugging
- =================
-
- The files m68k-stub.c, i386-stub.c, and sparc-stub.c are examples
- of remote stubs to be used with remote.c. They are designed to run
- standalone on an m68k, i386, or SPARC cpu and communicate properly
- with the remote.c stub over a serial line.
-
- The directory gdb/gdbserver/ contains `gdbserver', a program that
- allows remote debugging for Unix applications. gdbserver is only
- supported for some native configurations, including Sun 3, Sun 4, and
- Linux.
-
- There are a number of remote interfaces for talking to existing ROM
- monitors and other hardware:
-
- remote-adapt.c AMD 29000 "Adapt"
- remote-array.c Array Tech RAID controller
- remote-bug.c Motorola BUG monitor
- remote-e7000.c Hitachi E7000 ICE
- remote-eb.c AMD 29000 "EBMON"
- remote-es.c Ericsson 1800 monitor
- remote-est.c EST emulator
- remote-hms.c Hitachi Micro Systems H8/300 monitor
- remote-mips.c MIPS remote debugging protocol
- remote-mm.c AMD 29000 "minimon"
- remote-nindy.c Intel 960 "Nindy"
- remote-nrom.c NetROM ROM emulator
- remote-os9k.c PC running OS/9000
- remote-rdi.c ARM with Angel monitor
- remote-rdp.c ARM with Demon monitor
- remote-sds.c PowerPC SDS monitor
- remote-sim.c Generalized simulator protocol
- remote-st.c Tandem ST-2000 monitor
- remote-udi.c AMD 29000 using the AMD "Universal Debug Interface"
- remote-vx.c VxWorks realtime kernel
-
- Remote-vx.c and the vx-share subdirectory contain a remote
- interface for the VxWorks realtime kernel, which communicates over TCP
- using the Sun RPC library. This would be a useful starting point for
- other remote- via-ethernet back ends.
-
- Remote-udi.c and the 29k-share subdirectory contain a remote
- interface for AMD 29000 programs, which uses the AMD "Universal Debug
- Interface". This allows GDB to talk to software simulators,
- emulators, and/or bare hardware boards, via network or serial
- interfaces. Note that GDB only provides an interface that speaks UDI,
- not a complete solution. You will need something on the other end
- that also speaks UDI.
-
-
Reporting Bugs
===============
--- 426,439 ----
GDB or its supporting libraries.
! Host/target specific installation notes
! =======================================
! solaris??-64-???
+ Something goes here on how to set up a 64 bit build.
Reporting Bugs
===============
*************** command that you used when configuring G
*** 507,574 ****
For more information on how/whether to report bugs, see the GDB
Bugs section of the GDB manual (gdb/doc/gdb.texinfo) or the
gdb/CONTRIBUTE file.
-
- Known bugs:
-
- * Under Ultrix 4.2 (DECstation-3100) or Alphas under OSF/1, we have
- seen problems with backtraces after interrupting the inferior out
- of a read(). The problem is caused by ptrace() returning an
- incorrect value for the frame pointer register (register 15 or
- 30). As far as we can tell, this is a kernel problem. Any help
- with this would be greatly appreciated.
-
- * Under Ultrix 4.4 (DECstation-3100), setting the TERMCAP environment
- variable to a string without a trailing ':' can cause GDB to dump
- core upon startup. Although the core file makes it look as though
- GDB code failed, the crash actually occurs within a call to the
- termcap library function tgetent(). The problem can be solved by
- using the GNU Termcap library.
-
- Alphas running OSF/1 (versions 1.0 through 2.1) have the same buggy
- termcap code, but GDB behaves strangely rather than crashing.
-
- * On DECstations there are warnings about shift counts out of range in
- various BFD modules. None of them is a cause for alarm, they are actually
- a result of bugs in the DECstation compiler.
-
- * Notes for the DEC Alpha using OSF/1:
- The debugging output of native cc has two known problems; we view these
- as compiler bugs.
- The linker miscompacts symbol tables, which causes gdb to confuse the
- type of variables or results in `struct <illegal>' type outputs.
- dbx has the same problems with those executables. A workaround is to
- specify -Wl,-b when linking, but that will increase the executable size
- considerably.
- If a structure has incomplete type in one file (e.g., "struct foo *"
- without a definition for "struct foo"), gdb will be unable to find the
- structure definition from another file.
- It has been reported that the Ultrix 4.3A compiler on decstations has the
- same problems.
-
- * Notes for Solaris 2.x, using the SPARCworks cc compiler:
- You have to compile your program with the -xs option of the SPARCworks
- compiler to be able to debug your program with gdb.
- Under Solaris 2.3 you also need patch 101409-03 (Jumbo linker patch).
- Under Solaris 2.2, if you have patch 101052 installed, make sure
- that it is at least at revision 101052-06.
-
- * Under Irix 5 for SGIs, you must have installed the `compiler_dev.hdr'
- subsystem that is on the IDO CD, otherwise you will get complaints
- that certain files such as `/usr/include/syms.h' cannot be found.
-
- * Under Irix 6 you must build with GCC. The vendor compiler reports
- as errors certain assignments that GCC considers to be warnings.
-
- GDB can produce warnings about symbols that it does not understand.
- By default, these warnings are disabled. You can enable them by
- executing `set complaint 10' (which you can put in your ~/.gdbinit if
- you like). I recommend doing this if you are working on a compiler,
- assembler, linker, or GDB, since it will point out problems that you
- may be able to fix. Warnings produced during symbol reading indicate
- some mismatch between the object file and GDB's symbol reading code.
- In many cases, it's a mismatch between the specs for the object file
- format, and what the compiler actually outputs or the debugger
- actually understands.
Graphical interface to GDB -- X Windows, MS Windows
--- 450,455 ----