From: John Gilmore Date: Sun, 19 May 1991 16:01:39 +0000 (+0000) Subject: update for release X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=361cc81add84408732b45539da819e0c94323404;p=binutils-gdb.git update for release --- diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 622643113c5..38c76857a0e 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,5 +1,12 @@ Sun May 19 05:36:59 1991 John Gilmore (gnu at cygint.cygnus.com) + * README: Update for release. + * config.gdb: Don't create readline dir in subdir builds. + * main.c: Include with "..." form for non-system include files, + so "gcc -MM" for "make depend" works. + Include readline files with "...h" rather than . + * mipsread.c: Include "ecoff.h" rather than "intel-coff.h". + * coffread.c: Undo minor damage done by Rich Pixley. Use different internal and external representations of COFF data structures. Use new BFD routines for swapping them in and diff --git a/gdb/README b/gdb/README index 999db4a12f7..ed1d9fb6800 100644 --- a/gdb/README +++ b/gdb/README @@ -5,27 +5,37 @@ 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 PARTICULARLY FRAGILE! <= + => THIS VERSION IS FRAGILE! <= - It depends on a preliminary version of a new "binary file - descriptor" library and a new global "include" directory, which + 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 this library manually, then configure and build gdb. + and build these libraries manually, then configure and build gdb. When building gdb's for multiple platforms, you must manually - rebuild the bfd library separately for each platform. Yes, of + rebuild the libraries separately for each platform. Yes, of course, we are working on this! FIXME! - Configure bfd for your host system by: + Configure and build the libraries for your host system by: cd ../bfd - edit Makefile + ./configure HOSTNAME + make + + cd ../libiberty + ./configure HOSTNAME + make + + 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, -and the getopt routines into the parent directory of gdb. The idea -is that a variety of GNU tools can share a common copy of these things. +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'. @@ -56,16 +66,16 @@ configure it this way by specifying `config.gdb host 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 file provided with this distribution. -For details see the texinfo manual (distributed with emacs and as a -printed manual). +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). 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 problem, please send a bug report; note that you may have to refer to some FORTRAN variables with a trailing -underscore), but I am not aware of anyone who is working on getting it +underscore). I am not aware of anyone who is working on getting it 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. @@ -80,7 +90,7 @@ About remote debugging... [This section seems to be out of date, I have never seen the "rapp" program, though I would like to. FIXME.] -`rapp' runs under unix and acts as a remote stub (like remote-multi.shar +`rapp' runs under unix and acts as a remote stub (like rem-multi.shar distributed with GDB version 3). Currently it just works over UDP (network), not over a serial line. To get it running * Compile GDB on the host machine as usual @@ -90,13 +100,14 @@ distributed with GDB version 3). Currently it just works over UDP This will get reworked before the initial release of 4.x. FIXME. -The two files remote-multi.shar and remote-sa.m68k.shar contain two -examples of a remote stub to be used with remote.c. The the -multi -file is a general stub that can probably be running on various -different flavors of unix to allow debugging over a serial line from -one machine to another. The remote-sa.m68k.shar is designed to run -standalone on a 68k type cpu and communicate properley with the -remote.c stub over a serial line. +The files m68k-stub.c and i386-stub.c contain two examples of remote +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 +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 @@ -111,18 +122,9 @@ The correct address for reporting bugs found with gdb is About xgdb... -Hopefully a new xgdb will be in 4.x. +xgdb is obsolete. We are not doing any development or support of it. -xgdb.c was provided to us by the user community; it is not an integral -part of the gdb distribution. The problem of providing visual -debugging support on top of gdb is peripheral to the GNU project and -(at least right now) we can't afford to put time into it. So while we -will be happy to incorporate user fixes to xgdb.c, we do not guarantee -that it will work and we will not fix bugs reported in it. See -XGDB-README for one person's opinion about what is wrong with the -current xgdb. Someone is working on writing a new XGDB, so improving -(e.g. by fixing it so that it will work, if it doesn't currently) the -current one is not worth it. +There is an "xxgdb", which shows more promise. For those intersted in auto display of source and the availability of an editor while debugging I suggest trying gdb-mode in gnu-emacs @@ -212,7 +214,7 @@ symbols which need to be ignored on a specific machine. Calling IGNORE_SYMBOL in dbxread.c is a lot cleaner than a maze of #if defined's). The machine-independent code should do whatever "most" machines want if the macro is not defined in param.h. Using #if -defined can sometimes be OK (e.g. SET_STACK_LIMIT_HUGE) but should be +defined can sometimes be OK (e.g. SET_STACK_LIMIT_HUGE) but should be conditionalized on a specific feature of an operating system (set in tm.h or xm.h) rather than something like #if defined(vax) or #if defined(SYSV). If you use an #ifdef on some symbol that is defined