Change bug reporting email address.
This commit is contained in:
Nick Clifton
parent
e36118e765
commit
1b577b00bd
|
|
@ -1,3 +1,8 @@
|
|||
2001-07-19 Nick Clifton <nickc@cambridge.redhat.com>
|
||||
|
||||
* README: Update for 2.11. Change bug reporting email address.
|
||||
* MAINTAINERS: Tidy up. Change bug reporting email address.
|
||||
|
||||
2001-07-16 DJ Delorie <dj@redhat.com>
|
||||
|
||||
* resres.c (write_res_header): Align header size.
|
||||
|
|
|
|||
|
|
@ -1,88 +1,105 @@
|
|||
========= Binutils Maintainers =========
|
||||
|
||||
This is the list of individuals responsible for maintenance and update
|
||||
of the "binutils" module, which includes the bfd, binutils, include,
|
||||
gas, gprof, ld, and opcodes subdirectories. The home page for binutils
|
||||
is http://sources.redhat.com/binutils/ and patches should be sent to
|
||||
binutils@sources.redhat.com with "[patch]" as part of the subject.
|
||||
of the GNU Binary Utilities project. This includes the linker (ld),
|
||||
the assembler (gas), the profiler (gprof), a whole suite of other
|
||||
programs (binutils) and the libraries that they use (bfd and
|
||||
opcodes). This project shares a common set of header files with the
|
||||
GCC and GDB projects (include), so maintainership of those files is
|
||||
shared amoungst the projects.
|
||||
|
||||
Note - patches to the top level configure.in and config.sub scripts
|
||||
should be sent to config-patches@gnu.org and not to the binutils list.
|
||||
The home page for binutils is:
|
||||
|
||||
http://www.gnu.org/software/binutils/binutils.html
|
||||
|
||||
and patches should be sent to:
|
||||
|
||||
bug-gnu-utils@gnu.org
|
||||
|
||||
with "[Patch]" as part of the subject line. Note - patches to the
|
||||
top level configure.in and config.sub scripts should be sent to:
|
||||
|
||||
config-patches@gnu.org
|
||||
|
||||
and not to the binutils list.
|
||||
|
||||
--------- Blanket Write Privs ---------
|
||||
|
||||
Nick Clifton <nickc@redhat.com> (head maintainer)
|
||||
Richard Henderson <rth@redhat.com>
|
||||
Ian Taylor <ian@zembu.com>
|
||||
Jeff Law <law@redhat.com>
|
||||
Jim Wilson <wilson@redhat.com>
|
||||
DJ Delorie <dj@redhat.com>
|
||||
Alan Modra <amodra@bigpond.net.au>
|
||||
Michael Meissner <meissner@redhat.com>
|
||||
The following people have permission to check patches into the
|
||||
repository without obtaining approval first:
|
||||
|
||||
Nick Clifton <nickc@redhat.com> (head maintainer)
|
||||
Richard Henderson <rth@redhat.com>
|
||||
Ian Taylor <ian@zembu.com>
|
||||
Jeff Law <law@redhat.com>
|
||||
Jim Wilson <wilson@redhat.com>
|
||||
DJ Delorie <dj@redhat.com>
|
||||
Alan Modra <amodra@bigpond.net.au>
|
||||
Michael Meissner <meissner@redhat.com>
|
||||
|
||||
--------- Maintainers ---------
|
||||
--------- Maintainers ---------
|
||||
|
||||
Maintainers are individuals who are responsible for, and have permission
|
||||
to check in changes in, certain subsets of the code. Note that
|
||||
maintainers still need approval to check in changes outside of the
|
||||
immediate domain that they maintain.
|
||||
Maintainers are individuals who are responsible for, and have
|
||||
permission to check in changes in, certain subsets of the code. Note
|
||||
that maintainers still need approval to check in changes outside of
|
||||
the immediate domain that they maintain.
|
||||
|
||||
If there is no maintainer for a given domain then the responsibility
|
||||
falls to the head maintainer (above). If there are several maintainers
|
||||
for a given domain then responsibility falls to the first maintainer.
|
||||
The first maintainer is free to devolve that responsibility among the
|
||||
other maintainers.
|
||||
falls to the head maintainer (above). If there are several
|
||||
maintainers for a given domain then responsibility falls to the first
|
||||
maintainer. The first maintainer is free to devolve that
|
||||
responsibility among the other maintainers.
|
||||
|
||||
ARM Nick Clifton <nickc@redhat.com>
|
||||
AVR Denis Chertykov <denisc@overta.ru>
|
||||
CRIS Hans-Peter Nilsson <hp@axis.com>
|
||||
HPPA elf32 Alan Modra <amodra@bigpond.net.au>
|
||||
IA64 Jim Wilson <wilson@redhat.com>
|
||||
i860 Jason Eckhardt <jle@redhat.com>
|
||||
ix86 Alan Modra <amodra@bigpond.net.au>
|
||||
ix86 COFF,PE DJ Delorie <dj@redhat.com>
|
||||
ix86 H.J.Lu <hjl@gnu.org>
|
||||
ix86 INTEL MODE Diego Novillo <dnovillo@redhat.com>
|
||||
MN10300 Eric Christopher <echristo@redhat.com>
|
||||
MIPS Eric Christopher <echristo@redhat.com>
|
||||
M88k Ben Elliston <bje@redhat.com>
|
||||
PPC Geoff Keating <geoffk@redhat.com>
|
||||
SH Jörn Rennecke <amylaar@redhat.com>
|
||||
SH Hans-Peter Nilsson <hp@bitrange.com>
|
||||
SPARC Jakub Jelinek <jakub@redhat.com>
|
||||
68HC11 68HC12 Stephane Carrez <Stephane.Carrez@worldnet.fr>
|
||||
DWARF2 Jason Merrill <jason@redhat.com>
|
||||
x86_64 Jan Hubicka <jh@suse.cz>
|
||||
x86_64 Andreas Jaeger <aj@suse.de>
|
||||
z8k Christian Groessler <cpg@aladdin.de>
|
||||
ARM Nick Clifton <nickc@redhat.com>
|
||||
AVR Denis Chertykov <denisc@overta.ru>
|
||||
CRIS Hans-Peter Nilsson <hp@axis.com>
|
||||
DWARF2 Jason Merrill <jason@redhat.com>
|
||||
HPPA elf32 Alan Modra <amodra@bigpond.net.au>
|
||||
IA64 Jim Wilson <wilson@redhat.com>
|
||||
x86_64 Jan Hubicka <jh@suse.cz>
|
||||
x86_64 Andreas Jaeger <aj@suse.de>
|
||||
i860 Jason Eckhardt <jle@redhat.com>
|
||||
ix86 Alan Modra <amodra@bigpond.net.au>
|
||||
ix86 COFF,PE DJ Delorie <dj@redhat.com>
|
||||
ix86 H.J.Lu <hjl@gnu.org>
|
||||
ix86 INTEL MODE Diego Novillo <dnovillo@redhat.com>
|
||||
M68HC11 M68HC12 Stephane Carrez <Stephane.Carrez@worldnet.fr>
|
||||
MN10300 Eric Christopher <echristo@redhat.com>
|
||||
MIPS Eric Christopher <echristo@redhat.com>
|
||||
M88k Ben Elliston <bje@redhat.com>
|
||||
PPC Geoff Keating <geoffk@redhat.com>
|
||||
SH Jörn Rennecke <amylaar@redhat.com>
|
||||
SH Hans-Peter Nilsson <hp@bitrange.com>
|
||||
SPARC Jakub Jelinek <jakub@redhat.com>
|
||||
z8k Christian Groessler <cpg@aladdin.de>
|
||||
|
||||
--------- CGEN Maintainers -------------
|
||||
--------- CGEN Maintainers -------------
|
||||
|
||||
CGEN is a tool for building, amongst other things, assemblers,
|
||||
disassemblers and simulators from a single description of a CPU. It
|
||||
creates files in several of the binutils directories, but it is
|
||||
mentioned here since there is a single group that maintains CGEN and
|
||||
the files that it creates.
|
||||
disassemblers and simulators from a single description of a CPU.
|
||||
It creates files in several of the binutils directories, but it
|
||||
is mentioned here since there is a single group that maintains
|
||||
CGEN and the files that it creates.
|
||||
|
||||
If you have CGEN related problems you can send email to;
|
||||
|
||||
cgen@sources.redhat.com
|
||||
cgen@sources.redhat.com
|
||||
|
||||
The current CGEN maintainers are:
|
||||
|
||||
Doug Evans, Ben Elliston, Frank Eigler
|
||||
|
||||
--------- Write After Approval ---------
|
||||
--------- Write After Approval ---------
|
||||
|
||||
Individuals with "write after approval" have the ability to check in
|
||||
changes, but they must get approval for each change from someone in
|
||||
one of the above lists (blanket write or maintainers).
|
||||
|
||||
[It's a huge list, folks. You know who you are. If you have the
|
||||
*ability* to do binutils checkins, you're in this group. Just remember
|
||||
to get approval before checking anything in.]
|
||||
*ability* to do binutils checkins, you're in this group. Just
|
||||
remember to get approval before checking anything in.]
|
||||
|
||||
------------- Obvious Fixes -------------
|
||||
------------- Obvious Fixes -------------
|
||||
|
||||
Fixes for obvious mistakes do not need approval, and can be checked in
|
||||
right away, but the patch should still be sent to the binutils list.
|
||||
|
|
@ -93,7 +110,7 @@ also blatantly obvious), and so on. Obvious fixes should always be
|
|||
small, the larger they are, the more likely it is that they contain
|
||||
some un-obvious side effect or consequence.
|
||||
|
||||
--------- Branch Checkins ---------
|
||||
--------- Branch Checkins ---------
|
||||
|
||||
If a patch is approved for check in to the mainline sources, it can
|
||||
also be checked into the current release branch. Normally however
|
||||
|
|
@ -103,4 +120,4 @@ burden of maintaining the branch in sync with the mainline becomes too
|
|||
great). If you are uncertain as to whether a patch is appropriate for
|
||||
the branch, ask the branch maintainer. This is:
|
||||
|
||||
Philip Blundell <philb@gnu.org>
|
||||
Philip Blundell <philb@gnu.org>
|
||||
|
|
|
|||
|
|
@ -1,26 +1,31 @@
|
|||
README for BINUTILS
|
||||
|
||||
These are the GNU binutils. These are utilities of use when dealing
|
||||
with object files.
|
||||
with binary files, either object files or executables. These tools
|
||||
consist of the linker (ld), the assembler (gas), and the profiler
|
||||
(gprof) each of which have their own sub-directory named after them.
|
||||
There is also a collection of other binary tools, including the
|
||||
disassembler (objdump) in this directory. These tools make use of a
|
||||
pair of libraries (bfd and opcodes) and a common set of header files
|
||||
(include).
|
||||
|
||||
The linker (ld) is in a separate directory, which should be ../ld.
|
||||
Linker-specific notes are in ../ld/README.
|
||||
There are README and NEWS files in most of the program sub-directories
|
||||
which give more information about those specific programs.
|
||||
|
||||
As of version 2.5, the assembler (as) is also included in this package, in
|
||||
../gas. Assembler-specific notes can be found in ../gas/README.
|
||||
|
||||
Recent changes are in ./NEWS, ../ld/NEWS, and ../gas/NEWS.
|
||||
|
||||
Unpacking and Installation -- quick overview
|
||||
============================================
|
||||
|
||||
When you unpack the binutils-2.9.tar.gz file, you'll get a directory
|
||||
called something like `binutils-2.9', which contains various files and
|
||||
directories. Most of the files in the top directory are for
|
||||
information and for configuration. The actual source code is in
|
||||
subdirectories.
|
||||
When you unpack the binutils archive file, you will get a directory
|
||||
called something like `binutils-XXX', where XXX is the number of the
|
||||
release. (Probably 2.11.2 or higher). This directory contains
|
||||
various files and sub-directories. Most of the files in the top
|
||||
directory are for information and for configuration. The actual
|
||||
source code is in sub-directories.
|
||||
|
||||
To build binutils, you can just do:
|
||||
|
||||
cd binutils-2.9
|
||||
cd binutils-XXX
|
||||
./configure [options]
|
||||
make
|
||||
make install # copies the programs files into /usr/local/bin
|
||||
|
|
@ -33,7 +38,7 @@ If you have GNU make, we recommend building in a different directory:
|
|||
|
||||
mkdir objdir
|
||||
cd objdir
|
||||
../binutils-2.9/configure [options]
|
||||
../binutils-XXX/configure [options]
|
||||
make
|
||||
make install
|
||||
|
||||
|
|
@ -41,7 +46,9 @@ This relies on the VPATH feature of GNU make.
|
|||
|
||||
By default, the binutils will be configured to support the system on
|
||||
which they are built. When doing cross development, use the --target
|
||||
configure option to specify a different target.
|
||||
configure option to specify a different target, eg:
|
||||
|
||||
./configure --target=foo-elf
|
||||
|
||||
The --enable-targets option adds support for more binary file formats
|
||||
besides the default. List them as the argument to --enable-targets,
|
||||
|
|
@ -49,11 +56,15 @@ separated by commas. For example:
|
|||
|
||||
./configure --enable-targets=sun3,rs6000-aix,decstation
|
||||
|
||||
The name 'all' compiles in support for all valid BFD targets (this was
|
||||
the default in releases before 2.3):
|
||||
The name 'all' compiles in support for all valid BFD targets:
|
||||
|
||||
./configure --enable-targets=all
|
||||
|
||||
On 32-bit hosts though, this support will be restricted to 32-bit
|
||||
target unless the --enable-64-bit-bfd option is also used:
|
||||
|
||||
./configure --enable-64-bit-bfd --enable-targets=all
|
||||
|
||||
You can also specify the --enable-shared option when you run
|
||||
configure. This will build the BFD and opcodes libraries as shared
|
||||
libraries. You can use arguments with the --enable-shared option to
|
||||
|
|
@ -62,7 +73,7 @@ example, --enable-shared=bfd. The only potential shared libraries in
|
|||
a binutils release are bfd and opcodes.
|
||||
|
||||
The binutils will be linked against the shared libraries. The build
|
||||
step will attempt to place the correct library in the runtime search
|
||||
step will attempt to place the correct library in the run-time search
|
||||
path for the binaries. However, in some cases, after you install the
|
||||
binaries, you may have to set an environment variable, normally
|
||||
LD_LIBRARY_PATH, so that the system can find the installed libbfd
|
||||
|
|
@ -71,10 +82,11 @@ shared library.
|
|||
To build under openVMS/AXP, see the file makefile.vms in the top level
|
||||
directory.
|
||||
|
||||
|
||||
If you don't have ar
|
||||
====================
|
||||
|
||||
If your system does not already have an ar program, the normal
|
||||
If your system does not already have an 'ar' program, the normal
|
||||
binutils build process will not work. In this case, run configure as
|
||||
usual. Before running make, run this script:
|
||||
|
||||
|
|
@ -98,10 +110,10 @@ the ranlib program in order to build the distribution.
|
|||
Porting
|
||||
=======
|
||||
|
||||
Binutils-2.9 supports many different architectures, but there
|
||||
Binutils-2.11 supports many different architectures, but there
|
||||
are many more not supported, including some that were supported
|
||||
by earlier versions. We are hoping for volunteers to
|
||||
improve this situation.
|
||||
by earlier versions. We are hoping for volunteers to improve this
|
||||
situation.
|
||||
|
||||
The major effort in porting binutils to a new host and/or target
|
||||
architecture involves the BFD library. There is some documentation
|
||||
|
|
@ -111,10 +123,13 @@ with gdb-4.x) may also be of help.
|
|||
Reporting bugs
|
||||
==============
|
||||
|
||||
Send bug reports and patches to bug-binutils@gnu.org. Always mention
|
||||
the version number you are running; this is printed by running any of
|
||||
the binutils with the --version option. We appreciate reports about
|
||||
bugs, but we do not promise to fix them.
|
||||
Send bug reports and patches to:
|
||||
|
||||
bug-gnu-utils@gnu.org.
|
||||
|
||||
Always mention the version number you are running; this is printed by
|
||||
running any of the binutils with the --version option. We appreciate
|
||||
reports about bugs, but we do not promise to fix them.
|
||||
|
||||
VMS
|
||||
===
|
||||
|
|
@ -156,7 +171,7 @@ makefile.vms. Either select CC=cc (for DEC C) or CC=gcc (for GNU C)
|
|||
Installing the release
|
||||
|
||||
Provided that your directory setup conforms to the GNU on openVMS
|
||||
standard, you already have a concealed deviced named 'GNU_ROOT'.
|
||||
standard, you already have a concealed device named 'GNU_ROOT'.
|
||||
In this case, a simple
|
||||
|
||||
$ gmake install
|
||||
|
|
@ -179,7 +194,7 @@ and [.binutils]strings.exe) and the gnu assembler and preprocessor
|
|||
and define all programs as foreign commands.
|
||||
|
||||
|
||||
If you're satiesfied with the compilation, you may want to remove
|
||||
If you're satisfied with the compilation, you may want to remove
|
||||
unneeded objects and libraries:
|
||||
|
||||
$ gmake clean
|
||||
|
|
|
|||
30
gas/README
30
gas/README
|
|
@ -1,10 +1,10 @@
|
|||
README for GAS
|
||||
|
||||
A number of things have changed since version 1 and the wonderful world of gas
|
||||
looks very different. There's still a lot of irrelevant garbage lying around
|
||||
that will be cleaned up in time. Documentation is scarce, as are logs of the
|
||||
changes made since the last gas release. My apologies, and I'll try to get
|
||||
something useful.
|
||||
A number of things have changed since version 1 and the wonderful
|
||||
world of gas looks very different. There's still a lot of irrelevant
|
||||
garbage lying around that will be cleaned up in time. Documentation
|
||||
is scarce, as are logs of the changes made since the last gas release.
|
||||
My apologies, and I'll try to get something useful.
|
||||
|
||||
Unpacking and Installation - Summary
|
||||
====================================
|
||||
|
|
@ -31,7 +31,7 @@ system. You can rebuild it by typing:
|
|||
make as.dvi
|
||||
|
||||
The Info form is viewable with the GNU Emacs `info' subsystem, or the
|
||||
standalone `info' program, available as part of the GNU Texinfo distribution.
|
||||
stand-alone `info' program, available as part of the GNU Texinfo distribution.
|
||||
To build the info files, you will need the `makeinfo' program. Type:
|
||||
|
||||
cd gas/doc
|
||||
|
|
@ -142,7 +142,7 @@ The `--enable' options recognized by software in the gas distribution are:
|
|||
Supported platforms
|
||||
===================
|
||||
|
||||
At this point I believe gas to be ansi only code for most target cpu's. That
|
||||
At this point I believe gas to be ANSI only code for most target cpu's. That
|
||||
is, there should be relatively few, if any host system dependencies. So
|
||||
porting (as a cross-assembler) to hosts not yet supported should be fairly
|
||||
easy. Porting to a new target shouldn't be too tough if it's a variant of one
|
||||
|
|
@ -173,9 +173,10 @@ Native assembling should work on:
|
|||
sparc solaris
|
||||
ns32k (netbsd, lites)
|
||||
|
||||
I believe that gas as a cross-assembler can currently be targetted for
|
||||
I believe that gas as a cross-assembler can currently be targeted for
|
||||
most of the above hosts, plus
|
||||
|
||||
arm
|
||||
decstation-bsd (a.out format, to be used in BSD 4.4)
|
||||
ebmon29k
|
||||
go32 (DOS on i386, with DJGPP -- old a.out version)
|
||||
|
|
@ -229,10 +230,13 @@ warning message when this happens.
|
|||
REPORTING BUGS IN GAS
|
||||
=====================
|
||||
|
||||
Bugs in gas should be reported to bug-binutils@gnu.org. They may be
|
||||
cross-posted to bug-gcc if they affect the use of gas with gcc. They
|
||||
should not be reported just to bug-gcc, since I don't read that list,
|
||||
and therefore wouldn't see them.
|
||||
Bugs in gas should be reported to:
|
||||
|
||||
bug-gnu-utils@gnu.org.
|
||||
|
||||
They may be cross-posted to gcc-bugs@gnu.org if they affect the use of
|
||||
gas with gcc. They should not be reported just to gcc-bugs, since not
|
||||
all of the maintainers read that list.
|
||||
|
||||
If you report a bug in GAS, please remember to include:
|
||||
|
||||
|
|
@ -265,7 +269,7 @@ does demonstrate the problem; but if paring it down would cause large delays
|
|||
in filing the bug report, don't bother.
|
||||
|
||||
If the input file is very large, and you are on the internet, you may want to
|
||||
make it avaliable for anonymous FTP instead of mailing it. If you do, include
|
||||
make it available for anonymous FTP instead of mailing it. If you do, include
|
||||
instructions for FTP'ing it in your bug report.
|
||||
|
||||
If you expect to be contributing a large number of test cases, it would be
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
2001-07-19 Nick Clifton <nickc@cambridge.redhat.com>
|
||||
|
||||
* NOTES: Rename to README for consistency with other binutils.
|
||||
|
||||
2001-06-18 H.J. Lu <hjl@gnu.org>
|
||||
|
||||
* Makefile.am (diststuff): Add $(MANS).
|
||||
|
|
|
|||
|
|
@ -1,4 +1,8 @@
|
|||
Sun Feb 5 16:09:16 1995
|
||||
README for GPROF
|
||||
|
||||
This is the GNU profiler. It is distributed with other "binary
|
||||
utilities" which should be in ../binutils. See ../binutils/README for
|
||||
more general notes, including where to send bug reports.
|
||||
|
||||
This file documents the changes and new features available with this
|
||||
version of GNU gprof.
|
||||
|
|
@ -111,7 +115,7 @@ Here are some examples:
|
|||
you must use the colon notation explained
|
||||
below to specify a function from a specific
|
||||
source file. Sometimes, functionnames contain
|
||||
dots. In such cases, it is necessar to
|
||||
dots. In such cases, it is necessary to
|
||||
add a leading colon to the name. For example,
|
||||
":.mul" selects function ".mul".
|
||||
|
||||
|
|
@ -433,6 +437,6 @@ be used.
|
|||
IMPLEMENTATION NOTE: gcc -a can be used to instrument a program to
|
||||
record basic-block execution counts. However, the __bb_exit_func()
|
||||
that is currently present in libgcc2.c does not generate a gmon.out
|
||||
file in a suiteable format. This should be fixed for future releases
|
||||
file in a suitable format. This should be fixed for future releases
|
||||
of gcc. In the meantime, contact davidm@cs.arizona.edu for a version
|
||||
of __bb_exit_func() to is appropriate.
|
||||
|
|
@ -1,3 +1,7 @@
|
|||
2001-07-19 Nick Clifton <nickc@cambridge.redhat.com>
|
||||
|
||||
* README: Add header for consistency with other README files.
|
||||
|
||||
2001-07-14 H.J. Lu <hjl@gnu.org>
|
||||
|
||||
* emultempl/elf32.em (output_prev_sec_find): Never return
|
||||
|
|
|
|||
Loading…
Reference in New Issue