OpenE2K
/
binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Partial update to README for new configure script and new 

documentation make targets.
This commit is contained in:
Roland Pesch 1991-07-26 20:22:41 +00:00
parent 70b887611a
commit 170d0c8527
2 changed files with 105 additions and 50 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
gdb/ChangeLog
View File

@ -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) Tue Jul 23 18:52:43 1991 Roland H. Pesch (pesch at cygint.cygnus.com)
* Minor, mostly mechanical, cleanup of doc subdir for clean * Minor, mostly mechanical, cleanup of doc subdir for clean

129
gdb/README
View File

@ -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 and fixes mailed to bug-gdb, and the fixes in particular will move
into these sources as I find the time. 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.
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:
bfd gdb include libiberty readline texinfo
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.
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 When building gdb's for multiple platforms, you must manually
rebuild the libraries separately for each platform. Yes, of rebuild the libraries separately for each platform. FIXME FIXME no more!
course, we are working on this! FIXME! MENTION VPATH.
Configure and build the libraries for your host system by:
cd ../bfd
./configure HOSTNAME
make
cd ../libiberty
./configure HOSTNAME
make
cd ../readline cd ../readline
[edit Makefile as appropriate] [edit Makefile as appropriate]
make 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'. 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 The best way to build GDB (and the supporting libraries and include
a naming convention "=XXX" where XXX is the machine type I'm building files), in my opinion, is in subdirectories. The configure script
for. Nothing depends on this, it's just how I remember which does this automatically if you specify more than one HOSTNAME; you can
subdirectories are what. So, once you have the BFD library built for force it, even for one host only, by using configure's "+forcesubdirs"
that machine, you can do: 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).
cd gdb-x.yy (the directory where this README is) For example, you can do
mkdir =XXX (e.g. mkdir =vax)
cd =XXX cd .. (the directory *above* where this README is)
../config.gdb machine configure +f mymachine
cd Host-mymachine/Target-mymachine
make 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 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 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 sources, by specifying "-destdir=YYY" to ./configure, giving it an absolute
or relative path to the source directory. or relative path to the installation directory.
GDB can be used as a cross-debugger, running on a machine of one type 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 while debugging a program running on a machine of another type. You
configure it this way by specifying `config.gdb host target' where host configure it this way by specifying `./configure host -target=target'
is where GDB runs, and target is where your program runs. 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 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 can run, from the GDB source directory,
this distribution. For details see the texinfo manual (distributed make gdb.dvi
with emacs and as a printed manual). 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... About languages other than C...
C++ support has been integrated into gdb. GDB should work with FORTRAN 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 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 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 which use sets, subranges, file variables, or nested functions will not
currently work. 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 on a 68k or 386 cpu and communicate properly with the remote.c stub
over a serial line. over a serial line.
The file rem-multi.shar contains a general stub that can probably be The file rem-multi.shar contains a general stub that can probably
running on various different flavors of unix to allow debugging over a run on various different flavors of unix to allow debugging over a
serial line from one machine to another. serial line from one machine to another.
The files remote-eb.c and remote-nindy.c are two examples of remote 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 interfaces for talking to existing ROM monitors (for the AMD 29000 and the
Intel 960 repsectively). There is also a remote interface for the Intel 960 repsectively).
VxWorks realtime kernel, which communicates over TCP/IP, in remote-vx.c
and the vx-share subdirectory. 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... About reporting bugs...
@ -140,11 +165,11 @@ xconfig/<machine>
This contains Makefile stuff for when the host system is <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. 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 This file contains macro definitions that express information
about the target machine's registers, stack frame format and instructions. 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, This contains macro definitions describing the host system environment,
such as byte order, host C compiler and library, ptrace support, such as byte order, host C compiler and library, ptrace support,
and core file structure. and core file structure.