========= Binutils Maintainers =========
|
========= Binutils Maintainers =========
|
|
|
This is the list of individuals responsible for maintenance and update
|
This is the list of individuals responsible for maintenance and update
|
of the GNU Binary Utilities project. This includes the linker (ld),
|
of the GNU Binary Utilities project. This includes the linker (ld),
|
the assembler (gas), the profiler (gprof), a whole suite of other
|
the assembler (gas), the profiler (gprof), a whole suite of other
|
programs (binutils) and the libraries that they use (bfd and
|
programs (binutils) and the libraries that they use (bfd and
|
opcodes). This project shares a common set of header files with the
|
opcodes). This project shares a common set of header files with the
|
GCC and GDB projects (include), so maintainership of those files is
|
GCC and GDB projects (include), so maintainership of those files is
|
shared amoungst the projects.
|
shared amoungst the projects.
|
|
|
The home page for binutils is:
|
The home page for binutils is:
|
|
|
http://www.gnu.org/software/binutils/binutils.html
|
http://www.gnu.org/software/binutils/binutils.html
|
|
|
and patches should be sent to:
|
and patches should be sent to:
|
|
|
binutils@sourceware.org
|
binutils@sourceware.org
|
|
|
with "[Patch]" as part of the subject line. Note - patches to the
|
with "[Patch]" as part of the subject line. Note - patches to the
|
top level config.guess and config.sub scripts should be sent to:
|
top level config.guess and config.sub scripts should be sent to:
|
|
|
config-patches@gnu.org
|
config-patches@gnu.org
|
|
|
and not to the binutils lists. Patches to the other top level
|
and not to the binutils lists. Patches to the other top level
|
configure files (configure, configure.in, config-ml.in) should
|
configure files (configure, configure.in, config-ml.in) should
|
be sent to the binutils lists, and copied to the gcc and gdb
|
be sent to the binutils lists, and copied to the gcc and gdb
|
lists as well (gcc-patches@gcc.gnu.org and
|
lists as well (gcc-patches@gcc.gnu.org and
|
gdb-patches@sourceware.org).
|
gdb-patches@sourceware.org).
|
|
|
--------- Blanket Write Privs ---------
|
--------- Blanket Write Privs ---------
|
|
|
The following people have permission to check patches into the
|
The following people have permission to check patches into the
|
repository without obtaining approval first:
|
repository without obtaining approval first:
|
|
|
Nick Clifton (head maintainer)
|
Nick Clifton (head maintainer)
|
Richard Henderson
|
Richard Henderson
|
Ian Lance Taylor
|
Ian Lance Taylor
|
Jeff Law
|
Jeff Law
|
Jim Wilson
|
Jim Wilson
|
DJ Delorie
|
DJ Delorie
|
Alan Modra
|
Alan Modra
|
Michael Meissner
|
Michael Meissner
|
Daniel Jacobowitz
|
Daniel Jacobowitz
|
|
|
--------- Maintainers ---------
|
--------- Maintainers ---------
|
|
|
Maintainers are individuals who are responsible for, and have
|
Maintainers are individuals who are responsible for, and have
|
permission to check in changes in, certain subsets of the code. Note
|
permission to check in changes in, certain subsets of the code. Note
|
that maintainers still need approval to check in changes outside of
|
that maintainers still need approval to check in changes outside of
|
the immediate domain that they maintain.
|
the immediate domain that they maintain.
|
|
|
If there is no maintainer for a given domain then the responsibility
|
If there is no maintainer for a given domain then the responsibility
|
falls to the head maintainer (above). If there are several
|
falls to the head maintainer (above). If there are several
|
maintainers for a given domain then responsibility falls to the first
|
maintainers for a given domain then responsibility falls to the first
|
maintainer. The first maintainer is free to devolve that
|
maintainer. The first maintainer is free to devolve that
|
responsibility among the other maintainers.
|
responsibility among the other maintainers.
|
|
|
ALPHA Richard Henderson
|
ALPHA Richard Henderson
|
ARM Nick Clifton
|
ARM Nick Clifton
|
ARM Richard Earnshaw
|
ARM Richard Earnshaw
|
ARM Paul Brook
|
ARM Paul Brook
|
ARM (Symbian) Mark Mitchell
|
ARM (Symbian) Mark Mitchell
|
AVR Denis Chertykov
|
AVR Denis Chertykov
|
AVR Marek Michalkiewicz
|
AVR Marek Michalkiewicz
|
BFIN Jie Zhang
|
BFIN Jie Zhang
|
BFIN Bernd Schmidt
|
BFIN Bernd Schmidt
|
BUILD SYSTEM Ben Elliston
|
BUILD SYSTEM Ben Elliston
|
BUILD SYSTEM Daniel Jacobowitz
|
BUILD SYSTEM Daniel Jacobowitz
|
CR16 M R Swami Reddy
|
CR16 M R Swami Reddy
|
CRIS Hans-Peter Nilsson
|
CRIS Hans-Peter Nilsson
|
CRX M R Swami Reddy
|
CRX M R Swami Reddy
|
DLX Nikolaos Kavvadias
|
DLX Nikolaos Kavvadias
|
DWARF2 Jason Merrill
|
DWARF2 Jason Merrill
|
FR30 Dave Brolley
|
FR30 Dave Brolley
|
FRV Dave Brolley
|
FRV Dave Brolley
|
FRV Alexandre Oliva
|
FRV Alexandre Oliva
|
H8300 Anil Paranjpe
|
H8300 Anil Paranjpe
|
HPPA Dave Anglin
|
HPPA Dave Anglin
|
HPPA elf32 Alan Modra
|
HPPA elf32 Alan Modra
|
HPPA elf64 Jeff Law [Basic maintainance only]
|
HPPA elf64 Jeff Law [Basic maintainance only]
|
IA-64 Jim Wilson
|
IA-64 Jim Wilson
|
IQ2000 Stan Cox
|
IQ2000 Stan Cox
|
i860 Jason Eckhardt
|
i860 Jason Eckhardt
|
ix86 H.J. Lu
|
ix86 H.J. Lu
|
ix86 PE Christopher Faylor
|
ix86 PE Christopher Faylor
|
ix86 COFF DJ Delorie
|
ix86 COFF DJ Delorie
|
ix86 INTEL MODE Jan Beulich
|
ix86 INTEL MODE Jan Beulich
|
M68HC11 M68HC12 Stephane Carrez
|
M68HC11 M68HC12 Stephane Carrez
|
M68k Ben Elliston
|
M68k Ben Elliston
|
M88k Mark Kettenis
|
M88k Mark Kettenis
|
MAXQ Inderpreet Singh
|
MAXQ Inderpreet Singh
|
MEP Dave Brolley
|
MEP Dave Brolley
|
MIPS Eric Christopher
|
MIPS Eric Christopher
|
MIPS Thiemo Seufer
|
MIPS Thiemo Seufer
|
MMIX Hans-Peter Nilsson
|
MMIX Hans-Peter Nilsson
|
MN10300 Eric Christopher
|
MN10300 Eric Christopher
|
MN10300 Alexandre Oliva
|
MN10300 Alexandre Oliva
|
MSP430 Dmitry Diky
|
MSP430 Dmitry Diky
|
NetBSD support Matt Thomas
|
NetBSD support Matt Thomas
|
PPC Geoff Keating
|
PPC Geoff Keating
|
PPC Alan Modra
|
PPC Alan Modra
|
PPC vector ext Aldy Hernandez
|
PPC vector ext Aldy Hernandez
|
s390, s390x Martin Schwidefsky
|
s390, s390x Martin Schwidefsky
|
SCORE Mei Ligang
|
SCORE Mei Ligang
|
SH Alexandre Oliva
|
SH Alexandre Oliva
|
SH Kaz Kojima
|
SH Kaz Kojima
|
SPARC Jakub Jelinek
|
SPARC Jakub Jelinek
|
SPU Alan Modra
|
SPU Alan Modra
|
TESTSUITES Ben Elliston
|
TESTSUITES Ben Elliston
|
TIC4X Svein Seldal
|
TIC4X Svein Seldal
|
TIC54X Timothy Wall
|
TIC54X Timothy Wall
|
VAX Matt Thomas
|
VAX Matt Thomas
|
VAX Jan-Benedict Glaw
|
VAX Jan-Benedict Glaw
|
x86_64 Jan Hubicka
|
x86_64 Jan Hubicka
|
x86_64 Andreas Jaeger
|
x86_64 Andreas Jaeger
|
x86_64 H.J. Lu
|
x86_64 H.J. Lu
|
Xtensa Bob Wilson
|
Xtensa Bob Wilson
|
z80 Arnold Metselaar
|
z80 Arnold Metselaar
|
z8k Christian Groessler
|
z8k Christian Groessler
|
|
|
|
|
--------- CGEN Maintainers -------------
|
--------- CGEN Maintainers -------------
|
|
|
CGEN is a tool for building, amongst other things, assemblers,
|
CGEN is a tool for building, amongst other things, assemblers,
|
disassemblers and simulators from a single description of a CPU.
|
disassemblers and simulators from a single description of a CPU.
|
It creates files in several of the binutils directories, but it
|
It creates files in several of the binutils directories, but it
|
is mentioned here since there is a single group that maintains
|
is mentioned here since there is a single group that maintains
|
CGEN and the files that it creates.
|
CGEN and the files that it creates.
|
|
|
If you have CGEN related problems you can send email to;
|
If you have CGEN related problems you can send email to;
|
|
|
cgen@sourceware.org
|
cgen@sourceware.org
|
|
|
The current CGEN maintainers are:
|
The current CGEN maintainers are:
|
|
|
Doug Evans, Frank Eigler
|
Doug Evans, Frank Eigler
|
|
|
--------- Write After Approval ---------
|
--------- Write After Approval ---------
|
|
|
Individuals with "write after approval" have the ability to check in
|
Individuals with "write after approval" have the ability to check in
|
changes, but they must get approval for each change from someone in
|
changes, but they must get approval for each change from someone in
|
one of the above lists (blanket write or maintainers).
|
one of the above lists (blanket write or maintainers).
|
|
|
[It's a huge list, folks. You know who you are. If you have the
|
[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
|
*ability* to do binutils checkins, you're in this group. Just
|
remember to get approval before checking anything in.]
|
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
|
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.
|
right away, but the patch should still be sent to the binutils list.
|
The definition of obvious is a bit hazy, and if you are not sure, then
|
The definition of obvious is a bit hazy, and if you are not sure, then
|
you should seek approval first. Obvious fixes include fixes for
|
you should seek approval first. Obvious fixes include fixes for
|
spelling mistakes, blatantly incorrect code (where the correct code is
|
spelling mistakes, blatantly incorrect code (where the correct code is
|
also blatantly obvious), and so on. Obvious fixes should always be
|
also blatantly obvious), and so on. Obvious fixes should always be
|
small, the larger they are, the more likely it is that they contain
|
small, the larger they are, the more likely it is that they contain
|
some un-obvious side effect or consequence.
|
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
|
If a patch is approved for check in to the mainline sources, it can
|
also be checked into the current release branch. Normally however
|
also be checked into the current release branch. Normally however
|
only bug fixes should be applied to the branch. New features, new
|
only bug fixes should be applied to the branch. New features, new
|
ports, etc, should be restricted to the mainline. (Otherwise the
|
ports, etc, should be restricted to the mainline. (Otherwise the
|
burden of maintaining the branch in sync with the mainline becomes too
|
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
|
great). If you are uncertain as to whether a patch is appropriate for
|
the branch, ask the branch maintainer. This is:
|
the branch, ask the branch maintainer. This is:
|
|
|
Daniel Jacobowitz
|
Daniel Jacobowitz
|
|
|
-------- Testsuites ---------------
|
-------- Testsuites ---------------
|
|
|
In general patches to any of the binutils testsuites should be
|
In general patches to any of the binutils testsuites should be
|
considered generic and sent to the binutils mailing list for
|
considered generic and sent to the binutils mailing list for
|
approval. Patches to target specific tests are the responsibility the
|
approval. Patches to target specific tests are the responsibility the
|
relevent port maintainer(s), and can be approved/checked in by them.
|
relevent port maintainer(s), and can be approved/checked in by them.
|
Other testsuite patches need the approval of a blanket-write-priveleges
|
Other testsuite patches need the approval of a blanket-write-priveleges
|
person.
|
person.
|
|
|
-------- Configure patches ----------
|
-------- Configure patches ----------
|
|
|
Patches to the top level configure files (config.sub & config.guess)
|
Patches to the top level configure files (config.sub & config.guess)
|
are not the domain of the binutils project and they cannot be approved
|
are not the domain of the binutils project and they cannot be approved
|
by the binutils group. Instead they should be submitted to the config
|
by the binutils group. Instead they should be submitted to the config
|
maintainer at:
|
maintainer at:
|
|
|
config-patches@gnu.org
|
config-patches@gnu.org
|
|
|
--------- Creating Branches ---------
|
--------- Creating Branches ---------
|
|
|
Anyone with at least write-after-approval access may create a branch
|
Anyone with at least write-after-approval access may create a branch
|
to use for their own development purposes. In keeping with FSF
|
to use for their own development purposes. In keeping with FSF
|
policies, all patches applied to such a branch must come from people
|
policies, all patches applied to such a branch must come from people
|
with appropriate copyright assignments on file. All legal
|
with appropriate copyright assignments on file. All legal
|
requirements that would apply to any other contribution apply equally
|
requirements that would apply to any other contribution apply equally
|
to contributions on a branch.
|
to contributions on a branch.
|
|
|
Before creating the branch, you should select a name for the branch of
|
Before creating the branch, you should select a name for the branch of
|
the form:
|
the form:
|
|
|
binutils--
|
binutils--
|
|
|
where "org" is the initials of your organization, or your own initials
|
where "org" is the initials of your organization, or your own initials
|
if you are acting as an individual. For example, for a branch created
|
if you are acting as an individual. For example, for a branch created
|
by The GNUDist Company, "tgc" would be an appropriate choice for
|
by The GNUDist Company, "tgc" would be an appropriate choice for
|
"org". It's up to each organization to select an appropriate choice
|
"org". It's up to each organization to select an appropriate choice
|
for "name"; some organizations may use more structure than others, so
|
for "name"; some organizations may use more structure than others, so
|
"name" may contain additional hyphens.
|
"name" may contain additional hyphens.
|
|
|
Suppose that The GNUDist Company was creating a branch to develop a
|
Suppose that The GNUDist Company was creating a branch to develop a
|
port of Binutils to the FullMonty processor. Then, an appropriate
|
port of Binutils to the FullMonty processor. Then, an appropriate
|
choice of branch name would be:
|
choice of branch name would be:
|
|
|
binutils-tgc-fm
|
binutils-tgc-fm
|
|
|
A date stamp is not required as part of the name field, but some
|
A date stamp is not required as part of the name field, but some
|
organizations like to have one. If you do include the date, you
|
organizations like to have one. If you do include the date, you
|
should follow these rules:
|
should follow these rules:
|
|
|
1. The date should be the date that the branch was created.
|
1. The date should be the date that the branch was created.
|
|
|
2. The date should be numerical and in the form YYYYMMDD.
|
2. The date should be numerical and in the form YYYYMMDD.
|
|
|
For example:
|
For example:
|
|
|
binutils-tgc-fm_20050101
|
binutils-tgc-fm_20050101
|
|
|
would be appropriate if the branch was created on January 1st, 2005.
|
would be appropriate if the branch was created on January 1st, 2005.
|
|
|
Having selected the branch name, create the branch as follows:
|
Having selected the branch name, create the branch as follows:
|
|
|
1. Check out binutils, so that you have a CVS checkout corresponding
|
1. Check out binutils, so that you have a CVS checkout corresponding
|
to the initial state of your branch.
|
to the initial state of your branch.
|
|
|
2. Create a tag:
|
2. Create a tag:
|
|
|
cvs tag binutils---branchpoint
|
cvs tag binutils---branchpoint
|
|
|
That tag will allow you, and others, to easily determine what's
|
That tag will allow you, and others, to easily determine what's
|
changed on the branch relative to the initial state.
|
changed on the branch relative to the initial state.
|
|
|
3. Create the branch:
|
3. Create the branch:
|
|
|
cvs rtag -b -r binutils---branchpoint \
|
cvs rtag -b -r binutils---branchpoint \
|
binutils---branch
|
binutils---branch
|
|
|
4. Document the branch:
|
4. Document the branch:
|
|
|
Add a description of the branch to binutils/BRANCHES, and check
|
Add a description of the branch to binutils/BRANCHES, and check
|
that file in. All branch descriptions should be added to the
|
that file in. All branch descriptions should be added to the
|
HEAD revision of the file; it doesn't help to modify
|
HEAD revision of the file; it doesn't help to modify
|
binutils/BRANCHES on a branch!
|
binutils/BRANCHES on a branch!
|
|
|
Please do not commit any patches to a branch you did not create
|
Please do not commit any patches to a branch you did not create
|
without the explicit permission of the person who created the branch.
|
without the explicit permission of the person who created the branch.
|
|
|
