Partial update to README for new configure script and new

documentation make targets.

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index a8f8eba236b0368017acc786e031f0af04042c40..389b4facad858643106bdc9c0ca66cc94b68c109 100644 (file)
--- 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 ed1d9fb6800354ca5695414422cbccbfe32e9de1..c13e18cd386a6977ba8ac6d7f15ba39b4ad557b8 100644 (file)
--- 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.