diff options
| -rw-r--r-- | gdb/ChangeLog | 30 | ||||
| -rw-r--r-- | gdb/README | 127 |
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 @@ -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. |