Commit 252b5132 authored by Richard Henderson's avatar Richard Henderson

19990502 sourceware import


Too many changes to show.

To preserve performance only 1000 of 1000+ files are displayed.

This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
README for GNU development tools
This directory contains various GNU compilers, assemblers, linkers,
debuggers, etc., plus their support routines, definitions, and documentation.
If you are receiving this as part of a GDB release, see the file gdb/README.
If with a binutils release, see binutils/README; if with a libg++ release,
see libg++/README, etc. That'll give you info about this
package -- supported targets, how to use it, how to report bugs, etc.
It is now possible to automatically configure and build a variety of
tools with one command. To build all of the tools contained herein,
run the ``configure'' script here, e.g.:
To install them (by default in /usr/local/bin, /usr/local/lib, etc),
then do:
make install
(If the configure script can't determine your type of computer, give it
the name as an argument, for instance ``./configure sun4''. You can
use the script ``config.sub'' to test whether a name is recognized; if
it is, config.sub translates it to a triplet specifying CPU, vendor,
and OS.)
If you have more than one compiler on your system, it is often best to
explicitly set CC in the environment before running configure, and to
also set CC when running make. For example (assuming sh/bash/ksh):
CC=gcc ./configure
A similar example using csh:
setenv CC gcc
Much of the code and documentation enclosed is copyright by
the Free Software Foundation, Inc. See the file COPYING or
COPYING.LIB in the various directories, for a description of the
GNU General Public License terms under which you can copy the files.
REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info
on where and how to report problems.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
Preliminary Notes on Porting BFD
The 'host' is the system a tool runs *on*.
The 'target' is the system a tool runs *for*, i.e.
a tool can read/write the binaries of the target.
Porting to a new host
Pick a name for your host. Call that <host>.
(<host> might be sun4, ...)
Create a file hosts/<host>.mh.
Porting to a new target
Pick a name for your target. Call that <target>.
Call the name for your CPU architecture <cpu>.
You need to create <target>.c and config/<target>.mt,
and add a case for it to a case statements in bfd/ and
bfd/config.bfd, which associates each canonical host type with a BFD
host type (used as the base of the makefile fragment names), and to the
table in bfd/ which associates each target vector with
the .o files it uses.
config/<target>.mt is a Makefile fragment.
The following is usually enough:
See the list of cpu types in archures.c, or "ls cpu-*.c".
If your architecture is new, you need to add it to the tables
in bfd/archures.c, opcodes/, and binutils/objdump.c.
For more information about .mt and .mh files, see config/README.
The file <target>.c is the hard part. It implements the
bfd_target <target>_vec, which includes pointers to
functions that do the actual <target>-specific methods.
Porting to a <target> that uses the a.out binary format
In this case, the include file aout-target.h probaby does most
of what you need. The program gen-aout generates <target>.c for
you automatically for many a.out systems. Do:
make gen-aout
./gen-aout <target> > <target>.c
(This only works if you are building on the target ("native").
If you must make a cross-port from scratch, copy the most
similar existing file that includes aout-target.h, and fix what is wrong.)
Check the parameters in <target>.c, and fix anything that is wrong.
(Also let us know about it; perhaps we can improve gen-aout.c.)
Should be defined if <target> is big-endian.
See discussion in ../include/aout/aout64.h.
Number of bytes per word. (Usually 4 but can be 8.)
Number of bits per word. (Usually 32, but can be 64.)
Define if the extry point (start address of an
executable program) can be 0x0.
The address of the start of the text segemnt in
virtual memory. Normally, the same as the entry point.
Usually, the same as the TARGET_PAGE_SIZE.
Alignment needed for the data segment.
The name of the target, for run-time lookups.
Usually "a.out-<target>"
BFD is a an object file library. It permits applications to use the
same routines to process object files regardless of their format.
BFD is used by the GNU debugger, assembler, linker, and the binary
The documentation on using BFD is scanty and may be occasionally
incorrect. Pointers to documentation problems, or an entirely
rewritten manual, would be appreciated.
There is some BFD internals documentation in doc/bfdint.texi which may
help programmers who want to modify BFD.
BFD is normally built as part of another package. See the build
instructions for that package, probably in a README file in the
appropriate directory.
BFD supports the following configure options:
The default target for which to build the library. TARGET is
a configuration target triplet, such as sparc-sun-solaris.
Additional targets the library should support. To include
support for all known targets, use --enable-targets=all.
Include support for 64 bit targets. This is automatically
turned on if you explicitly request a 64 bit target, but not
for --enable-targets=all. This requires a compiler with a 64
bit integer type, such as gcc.
Build BFD as a shared library.
Use mmap when accessing files. This is faster on some hosts,
but slower on others. It may not work on all hosts.
Report bugs with BFD to
Patches are encouraged. When sending patches, always send the output
of diff -u or diff -c from the original file to the new file. Do not
send default diff output. Do not make the diff from the new file to
the original file. Remember that any patch must not break other
systems. Remember that BFD must support cross compilation from any
host to any target, so patches which use ``#ifdef HOST'' are not
acceptable. Please also read the ``Reporting Bugs'' section of the
gcc manual.
Bug reports without patches will be remembered, but they may never get
fixed until somebody volunteers to fix them.
Things that still need to be done: -*- Text -*-
o - A source of space lossage is that all the target-dependent code
is in a single bfd_target structure. Hence all the code for
*writing* object files is still pulled into all the applications
that only care about *reading* (gdb, nm, objdump), while gas has
to carry along all the unneeded baggage for reading objects. And
so on. This would be a substantial change, and the payoff would
not all that great (essentially none if bfd is used as a shared
o - The storage needed by BFD data structures is also larger than strictly
needed. This may be difficult to do much about.
o - implement bfd_abort, which should close the bfd but not alter the
o - update the bfd doc; write a how-to-write-a-backend doc, take out
the stupid quips and fill in all the blanks.
o - upgrade the reloc handling as per Steve's suggestion.
dnl See whether we need to use fopen-bin.h rather than fopen-same.h.
case "${host}" in
*-*-msdos* | *-*-go32* | *-*-mingw32* | *-*-cygwin* | *-*-windows)
AC_DEFINE(USE_BINARY_FOPEN, 1, [Use b modifier when opening binary files?]) ;;
dnl Get a default for CC_FOR_BUILD to put into Makefile.
[# Put a plausible default for CC_FOR_BUILD in Makefile.
if test -z "$CC_FOR_BUILD"; then
if test "x$cross_compiling" = "xno"; then
if test "x$cross_compiling" = "xno"; then
AC_CACHE_CHECK([for build system executable suffix], bfd_cv_build_exeext,
[cat > ac_c_test.c << 'EOF'
int main() {
/* Nothing needed here */
${CC_FOR_BUILD} -o ac_c_test am_c_test.c 1>&5 2>&5
bfd_cv_build_exeext=`echo ac_c_test.* | grep -v ac_c_test.c | sed -e s/ac_c_test//`
rm -f ac_c_test*