Partial update to README for new configure script and new

documentation make targets.

2 files changed, 106 insertions, 51 deletions

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index a8f8eba..389b4fa 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,33 @@
+Fri Jul 26 13:20:02 1991  Roland H. Pesch  (pesch at cygint.cygnus.com)
+
+	* Partial update to README (which still needs work for this
+	release!): (1) use of configure corrected for new script, 
+                   (2) "make gdb.dvi" and "make gdb.info" mentioned.
+
+Wed Jul 24 06:44:02 1991  John Gilmore  (gnu at cygint.cygnus.com)
+
+	* symtab.c (lookup_symbol):  Don't complain right off about
+	no debug symbols; use the misc function vector first.
+	(list_symbols):  Use misc function vector to find symbols
+	that don't have debug info, and print them.
+	(find_pc_symtab):  Temporarily avoid fatal() when psymtab
+	PC range doesn't match symtab PC range, as it does on the 
+	MIPS because our symtab reading isn't perfect.
+
+	* dbxread.c (dbx_symfile_read):  Make warning about
+	"no debug symbols" slightly nicer.
+
+	* source.c (select_source_symtab):  If "main" symbol exists,
+	but decode_line_spec can't find line info, don't just return
+	a zero; try other source symtabs or give an error.
+
+	* mipsread.c (parse_partial_symbols):  Sort the psymtabs by
+	their low addresses first, then rip through fixing high addrs.
+
+	* ns32k-opcode.h (sfsr):  Bugfix from Rune Nerg}rd,
+	<runene@ifi.uio.no>.
+	(NS32K_SVC_IMMED_OPERANDS):  Reverse the #ifndef.
+
 Tue Jul 23 18:52:43 1991  Roland H. Pesch  (pesch at cygint.cygnus.com)
 
 	* Minor, mostly mechanical, cleanup of doc subdir for clean 
diff --git a/gdb/README b/gdb/README
index ed1d9fb..c13e18c 100644
--- a/gdb/README
+++ b/gdb/README
@@ -5,77 +5,99 @@ present in version 3 and new bugs.  I have filed all the bug reports
 and fixes mailed to bug-gdb, and the fixes in particular will move
 into these sources as I find the time.
 
-	      => THIS VERSION IS FRAGILE! <=
+This release moves the generic GNU include files, the BFD ("binary
+file description") library, the
+getopt routines, obstacks, and the readline library into the parent
+directory of gdb.  The idea is that a variety of GNU tools can share a
+common copy of these things.
 
-	It depends on preliminary versions of a new "binary file
-	descriptor" library, a new global "include" directory, 
-	and separate libraries for "readline" and "libiberty", which
-	are packaged separately from GDB.  You must obtain, configure
-	and build these libraries manually, then configure and build gdb.
-	When building gdb's for multiple platforms, you must manually
-	rebuild the libraries separately for each platform.  Yes, of
-	course, we are working on this!  FIXME!
+These generic files are packaged separately from GDB.  You must obtain
+them separately from GDB, and unpack them into the same directory, so
+that the directories:
 
-	Configure and build the libraries for your host system by:
+	bfd	gdb	include	libiberty	readline	texinfo
 
-		cd ../bfd
-		./configure HOSTNAME
-		make
+are all in the same directory.  There should also be a "configure"
+script (and its parameters, in "configure.in" and "Makefile.in"),
+in the same place.
+
+Once you have this stuff unpacked, you can cd to the directory in which
+you unpacked them, and type:
+
+	./configure HOSTNAME
+	make
+
+and all the libraries, as well as GDB will be configured and built.
 
-		cd ../libiberty
-		./configure HOSTNAME
-		make
+
+When building gdb's for multiple platforms, you must manually
+rebuild the libraries separately for each platform.	FIXME FIXME no more!
+MENTION VPATH.
 
 		cd ../readline
 		[edit Makefile as appropriate]
 		make
 
-	Then you can cd ../gdb-whatever, and config and build gdb.
-
-This release moves the generic GNU include files, the BFD library, the
-getopt routines, obstacks, and the readline library into the parent
-directory of gdb.  The idea is that a variety of GNU tools can share a
-common copy of these things.
-
 A summary of features new since gdb-3.5 is in the file `WHATS.NEW'.
 
-The best way to build GDB, in my opinion, is in a subdirectory.  I use
-a naming convention "=XXX" where XXX is the machine type I'm building
-for.  Nothing depends on this, it's just how I remember which
-subdirectories are what.  So, once you have the BFD library built for
-that machine, you can do:
-
-	cd gdb-x.yy	(the directory where this README is)
-	mkdir =XXX	(e.g. mkdir =vax)
-	cd =XXX
-	../config.gdb machine
+The best way to build GDB (and the supporting libraries and include
+files), in my opinion, is in subdirectories.  The configure script
+does this automatically if you specify more than one HOSTNAME; you can
+force it, even for one host only, by using configure's "+forcesubdirs"
+option (which you can abbreviate to +f).  configure will create two
+directory levels, Host-machine and Target-machine.   "machine"
+depends on your configuration options; the two directory levels
+reflect the fact that GDB can be configured for cross-debugging
+(described further below).
+
+For example, you can do
+
+	cd ..		(the directory *above* where this README is)
+	configure +f mymachine
+	cd Host-mymachine/Target-mymachine
 	make
 
-Machine is like "vax" or "sun4".  For more information type `../config.gdb'.
+Machine is like "vax" or "sun4".  For more information type
+`./configure'.  For a list of host machines, see the "xconfig"
+directory; for a list of targets, see the "tconfig" directory.
+
 
 Once you have done that, just `make' will do everything, producing an
-executable `gdb' in this directory.
+executable `gdb' in this directory.  You can install it anywhere; it has
+no hardwired paths in it.  However, you should make sure that the shell
+on your path (named by the SHELL environment variable) is publicly
+readable; various systems refuse to let GDB debug child programs which
+are not readable, and GDB uses the shell to start your program.
 
 You can also build gdb binaries in a completely different directory from its 
-sources, by specifying "srcdir=YYY" to config.gdb, giving it an absolute
-or relative path to the source directory.  
+sources, by specifying "-destdir=YYY" to ./configure, giving it an absolute
+or relative path to the installation directory.  
 
 GDB can be used as a cross-debugger, running on a machine of one type
 while debugging a program running on a machine of another type.  You
-configure it this way by specifying `config.gdb host target' where host
-is where GDB runs, and target is where your program runs.
+configure it this way by specifying `./configure host -target=target'
+where host is where GDB runs, and target is where your program runs.
 
 If you want a new (current to this release) version of the manual, you
-will have to use the gdb.texinfo and texinfo.tex files provided with
-this distribution.  For details see the texinfo manual (distributed
-with emacs and as a printed manual).
+can run, from the GDB source directory,
+	make gdb.dvi
+to make the TeX device-independent output file, or
+	make gdb.info 
+to make the "info" version for online browsing.  The former assumes
+you have a running TeX on your system; the latter, a running makeinfo.
+The source for the GDB manual is in the doc/gdb.texinfo file (and a
+few other files it includes) provided with this distribution.  The
+Makefile attempts to use a texinfo.tex from a "texinfo" directory
+parallel to the GDB directory (../texinfo/texinfo.tex, from the
+directory where this README is).  For details see the texinfo manual
+(distributed with emacs and as a printed manual).
 
 About languages other than C...
 
 C++ support has been integrated into gdb.  GDB should work with FORTRAN
-programs.  (If you have problem, please send a bug report; note that you
+programs.  (If you have problems, please send a bug report; you
 may have to refer to some FORTRAN variables with a trailing
-underscore).  I am not aware of anyone who is working on getting it
+underscore).  I am not aware of anyone who is working on getting gdb
 to use the syntax of any language other than C or C++.  Pascal programs
 which use sets, subranges, file variables, or nested functions will not
 currently work.
@@ -105,15 +127,18 @@ stubs to be used with remote.c.  They are designeded to run standalone
 on a 68k or 386 cpu and communicate properly with the remote.c stub
 over a serial line.
 
-The file rem-multi.shar contains a general stub that can probably be
-running on various different flavors of unix to allow debugging over a
+The file rem-multi.shar contains a general stub that can probably
+run on various different flavors of unix to allow debugging over a
 serial line from one machine to another.
 
 The files remote-eb.c and remote-nindy.c are two examples of remote
 interfaces for talking to existing ROM monitors (for the AMD 29000 and the
-Intel 960 repsectively).  There is also a remote interface for the
-VxWorks realtime kernel, which communicates over TCP/IP, in remote-vx.c
-and the vx-share subdirectory.
+Intel 960 repsectively).
+
+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.
 
 About reporting bugs...
 
@@ -140,11 +165,11 @@ xconfig/<machine>
 This contains Makefile stuff for when the host system is <machine>.
 It also specifies the name of the xm-XXX.h file for this machine.
 
-tm-XXX.h (tm.h is a link to this file, created by config.gdb).
+tm-XXX.h (tm.h is a link to this file, created by configure).
 This file contains macro definitions that express information
 about the target machine's registers, stack frame format and instructions.
 
-xm-XXX.h (xm.h is a link to this file, created by config.gdb).
+xm-XXX.h (xm.h is a link to this file, created by configure).
 This contains macro definitions describing the host system environment,
 such as byte order, host C compiler and library, ptrace support,
 and core file structure.