This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

[rfc/5.1] README clean out


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]