1 ========= Binutils Maintainers ========= 2 3 This is the list of individuals responsible for maintenance and update 4 of the GNU Binary Utilities project. This includes the linker (ld), 5 the assembler (gas), the profiler (gprof), a whole suite of other 6 programs (binutils) and the libraries that they use (bfd and 7 opcodes). This project shares a common set of header files with the 8 GCC and GDB projects (include), so maintainership of those files is 9 shared amongst the projects. 10 11 The home page for binutils is: 12 13 http://www.gnu.org/software/binutils/binutils.html 14 15 and patches should be sent to: 16 17 binutils (a] sourceware.org 18 19 with "[Patch]" as part of the subject line. Note - patches to the 20 top level config.guess and config.sub scripts should be sent to: 21 22 config-patches (a] gnu.org 23 24 and not to the binutils lists. Patches to the other top level 25 configure files (configure, configure.ac, config-ml.in) should 26 be sent to the binutils lists, and copied to the gcc and gdb 27 lists as well (gcc-patches (a] gcc.gnu.org and 28 gdb-patches (a] sourceware.org). 29 30 Patches to the libiberty sources should be sent to 31 gcc-patches (a] gcc.gnu.org. 32 33 --------- Blanket Write Privs --------- 34 35 The following people have permission to check patches into the 36 repository without obtaining approval first: 37 38 Nick Clifton <nickc (a] redhat.com> (head maintainer) 39 Ian Lance Taylor <ian (a] airs.com> 40 Jeff Law <law (a] redhat.com> 41 Jim Wilson <wilson (a] tuliptree.org> 42 DJ Delorie <dj (a] redhat.com> 43 Alan Modra <amodra (a] gmail.com> 44 Michael Meissner <gnu (a] the-meissners.org> 45 Richard Sandiford <rdsandiford (a] googlemail.com> 46 Jan Beulich <jbeulich (a] suse.com> 47 48 GDB global maintainers also have permission to commit and approve 49 patches to the top level files and to those parts of bfd files 50 primarily used by GDB. 51 52 --------- Maintainers --------- 53 54 Maintainers are individuals who are responsible for, and have 55 permission to check in changes in, certain subsets of the code. Note 56 that maintainers still need approval to check in changes outside of 57 the immediate domain that they maintain. 58 59 If there is no maintainer for a given domain then the responsibility 60 falls to the head maintainer (above). If there are several 61 maintainers for a given domain then responsibility falls to the first 62 maintainer. The first maintainer is free to devolve that 63 responsibility among the other maintainers. 64 65 AARCH64 Richard Earnshaw <rearnsha (a] arm.com> 66 AARCH64 Alice Carlotti <alice.carlotti (a] arm.com> 67 ARC Claudiu Zissulescu <claziss (a] gmail.com> 68 ARM Nick Clifton <nickc (a] redhat.com> 69 ARM Richard Earnshaw <rearnsha (a] arm.com> 70 ARM Ramana Radhakrishnan <ramana.radhakrishnan (a] arm.com> 71 AVR Denis Chertykov <chertykov (a] gmail.com> 72 AVR Marek Michalkiewicz <marekm (a] amelek.gda.pl> 73 BFIN Jie Zhang <jzhang918 (a] gmail.com> 74 BFIN Mike Frysinger <vapier (a] gentoo.org> 75 BPF Jose E. Marchesi <jose.marchesi (a] oracle.com> 76 CRIS Hans-Peter Nilsson <hp (a] axis.com> 77 CTF Nick Alcock <nick.alcock (a] oracle.com> 78 C-SKY Lifang Xia <lifang_xia (a] linux.alibaba.com> 79 C-SKY Yunhai Shang <yunhai (a] linux.alibaba.com> 80 DLX Nikolaos Kavvadias <nkavv (a] physics.auth.gr> 81 DWARF2 Jason Merrill <jason (a] redhat.com> 82 DWARF2 Jakub Jelinek <jakub (a] redhat.com> 83 dwarf-mode.el Tom Tromey <tom (a] tromey.com> 84 EPIPHANY Joern Rennecke <joern.rennecke (a] embecosm.com> 85 FR30 Nick Clifton <nickc (a] redhat.com> 86 FRV Nick Clifton <nickc (a] redhat.com> 87 FRV Alexandre Oliva <aoliva (a] sourceware.org> 88 GOLD Ian Lance Taylor <iant (a] google.com> 89 GOLD Cary Coutant <ccoutant (a] gmail.com> 90 gprofng Vladimir Mezentsev <vladimir.mezentsev (a] oracle.com> 91 HPPA Dave Anglin <dave.anglin (a] bell.net> 92 HPPA elf64 Jeff Law <law (a] redhat.com> [Basic maintainance only] 93 IA-64 Jim Wilson <wilson (a] tuliptree.org> 94 ix86 H.J. Lu <hjl.tools (a] gmail.com> 95 ix86 COFF DJ Delorie <dj (a] redhat.com> 96 ix86 PE/COFF Dave Korn <dave.korn.cygwin (a] gmail.com> 97 ix86 INTEL MODE Jan Beulich <jbeulich (a] suse.com> 98 KVX Paul Iannetta <piannetta (a] kalrayinc.com> 99 libsframe Indu Bhagat <indu.bhagat (a] oracle.com> 100 LM32 Jon Beniston <jon (a] beniston.com> 101 LoongArch Chenghua Xu <xuchenghua (a] loongson.cn> 102 LoongArch Zhensong Liu <liuzhensong (a] loongson.cn> 103 M32R Doug Evans <dje (a] sebabeach.org> 104 M68HC11 M68HC12 Stephane Carrez <Stephane.Carrez (a] gmail.com> 105 M68HC11 M68HC12 Sean Keys <skeys (a] ipdatasys.com> 106 MACH-O Tristan Gingold <tgingold (a] free.fr> 107 MAXQ Inderpreet Singh <inderpreetb (a] noida.hcltech.com> 108 MEP Nick Clifton <nickc (a] redhat.com> 109 MICROBLAZE Michael Eager <eager (a] eagercon.com> 110 MIPS Chenghua Xu <paul.hua.gm (a] gmail.com> 111 MIPS I-IV Maciej W. Rozycki <macro (a] orcam.me.uk> 112 MMIX Hans-Peter Nilsson <hp (a] bitrange.com> 113 MN10300 Alexandre Oliva <aoliva (a] sourceware.org> 114 Moxie Anthony Green <green (a] moxielogic.com> 115 NDS32 Kuan-Lin Chen <kuanlinchentw (a] gmail.com> 116 NDS32 Wei-Cheng Wang <cole945 (a] gmail.com> 117 OR1K Christian Svensson <blue (a] cmd.nu> 118 OR1K Stefan Kristiansson <stefan.kristiansson (a] saunalahti.fi> 119 OR1K Stafford Horne <shorne (a] gmail.com> 120 PPC Surya Kumari Jangala <jskumari (a] linux.ibm.com> 121 PPC Peter Bergner <bergner (a] tenstorrent.com> 122 PPC vector ext Aldy Hernandez <aldyh (a] redhat.com> 123 RISC-V Palmer Dabbelt <palmer (a] dabbelt.com> 124 RISC-V Andrew Waterman <andrew (a] sifive.com> 125 RISC-V Jim Wilson <jim.wilson.gcc (a] gmail.com> 126 RISC-V Nelson Chu <nelson (a] rivosinc.com> 127 RX Nick Clifton <nickc (a] redhat.com> 128 S12Z John Darrington <john (a] darrington.wattle.id.au> 129 s390, s390x Andreas Krebbel <krebbel (a] linux.ibm.com> 130 SH Alexandre Oliva <aoliva (a] sourceware.org> 131 SPARC David S. Miller <davem (a] davemloft.net> 132 SPARC Jose E. Marchesi <jose.marchesi (a] oracle.com> 133 SPU Alan Modra <amodra (a] gmail.com> 134 TIC54X Timothy Wall <twall (a] alum.mit.edu> 135 TIC6X Joseph Myers <josmyers (a] redhat.com> 136 VAX Jan-Benedict Glaw <jbglaw (a] lug-owl.de> 137 Visium Eric Botcazou <ebotcazou (a] libertysurf.fr> 138 VMS Tristan Gingold <tgingold (a] free.fr> 139 x86_64 Jan Beulich <jbeulich (a] suse.com> 140 x86_64 Jan Hubicka <jh (a] suse.cz> 141 x86_64 Andreas Jaeger <aj (a] suse.de> 142 x86_64 H.J. Lu <hjl.tools (a] gmail.com> 143 XCOFF Richard Sandiford <r.sandiford (a] uk.ibm.com> 144 XGATE Sean Keys <skeys (a] ipdatasys.com> 145 Xtensa Max Filippov <jcmvbkbc (a] gmail.com> 146 Xtensa Sterling Augustine <augustine.sterling (a] gmail.com> 147 z8k Christian Groessler <chris (a] groessler.org> 148 149 --------- Past Maintainers ------------- 150 151 These folks have acted as maintainers in the past, but have now 152 moved on to other things. Our thanks for all their hard work 153 goes with them. 154 155 Paul Brook 156 Eric Christopher 157 Jason Eckhardt 158 Geoff Keating 159 Mark Kettenis 160 Walter Lee 161 Mei Ligang 162 Arnold Metselaar 163 Mark Mitchell 164 Bernd Schmidt 165 Svein Seldal 166 M R Swami Reddy 167 Martin Schwidefsky 168 Matt Thomas 169 170 --------- CGEN Maintainers ------------- 171 172 CGEN is a tool for building, amongst other things, assemblers, 173 disassemblers and simulators from a single description of a CPU. 174 It creates files in several of the binutils directories, but it 175 is mentioned here since there is a single group that maintains 176 CGEN and the files that it creates. 177 178 If you have CGEN related problems you can send email to; 179 180 cgen (a] sourceware.org 181 182 The current CGEN maintainers are: 183 184 Doug Evans, Frank Eigler 185 186 --------- Write After Approval --------- 187 188 Individuals with "write after approval" have the ability to check in 189 changes, but they must get approval for each change from someone in 190 one of the above lists (blanket write or maintainers). 191 192 [It's a huge list, folks. You know who you are. If you have the 193 *ability* to do binutils checkins, you're in this group. Just 194 remember to get approval before checking anything in.] 195 196 ------------- Obvious Fixes ------------- 197 198 Fixes for obvious mistakes do not need approval, and can be checked in 199 right away, but the patch should still be sent to the binutils list. 200 The definition of obvious is a bit hazy, and if you are not sure, then 201 you should seek approval first. Obvious fixes include fixes for 202 spelling mistakes, blatantly incorrect code (where the correct code is 203 also blatantly obvious), and so on. Obvious fixes should always be 204 small, the larger they are, the more likely it is that they contain 205 some un-obvious side effect or consequence. 206 207 Obvious fixes should not be "legally significant", as defined here: 208 209 https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant 210 211 -------- Patches and Copyright --------- 212 213 If a patch is non-obvious, its copyright must be considered. There 214 are two ways to handle this. The first is to assign the copyright 215 of the FSF. This ensures that if problems with the authorship of the 216 patch arise, the FSF will be able to deal with them. 217 218 The list of already assigned copyrights can be obtained from 219 fencepost.gnu.org in the file: /gd/gnuorg/copyright.list. 220 221 New copyright assignments can be obtained by completing one of the 222 forms found here and sending it off to the FSF: 223 224 https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=tree;f=doc/Copyright 225 226 The alternative is to sign off the contribution by agreeing to the 227 Developer's Certificate of Origin (version 1.1 or later) and adding a 228 line to the end of the contribution that looks something like this: 229 230 Signed-off-by: Random J Developer <random (a] developer.example.org> 231 232 The details of the Developer's Certificate or Origin can be found here: 233 234 https://developercertificate.org/ 235 236 --------- Branch Checkins --------- 237 238 If a patch is approved for check in to the mainline sources, it can 239 also be checked into the current release branch. Normally however 240 only bug fixes should be applied to the branch. New features, new 241 ports, etc, should be restricted to the mainline. (Otherwise the 242 burden of maintaining the branch in sync with the mainline becomes too 243 great). If you are uncertain as to whether a patch is appropriate for 244 the branch, ask the branch maintainer. This is: 245 246 (cf global maintainers) 247 248 -------- Testsuites --------------- 249 250 In general patches to any of the binutils testsuites should be 251 considered generic and sent to the binutils mailing list for 252 approval. Patches to target specific tests are the responsibility the 253 relevant port maintainer(s), and can be approved/checked in by them. 254 Other testsuite patches need the approval of a blanket-write-priveleges 255 person. 256 257 -------- Configure patches ---------- 258 259 Patches to the top level configure files (config.sub & config.guess) 260 are not the domain of the binutils project and they cannot be approved 261 by the binutils group. Instead they should be submitted to the config 262 maintainer at: 263 264 config-patches (a] gnu.org 265 266 --------- Creating Branches --------- 267 268 Anyone with at least write-after-approval access may create a branch 269 to use for their own development purposes. In keeping with FSF 270 policies, all patches applied to such a branch must come from people 271 with appropriate copyright assignments on file. All legal 272 requirements that would apply to any other contribution apply equally 273 to contributions on a branch. 274 275 Before creating the branch, you should select a name for the branch of 276 the form: 277 278 binutils-<org>-<name> 279 280 where "org" is the initials of your organization, or your own initials 281 if you are acting as an individual. For example, for a branch created 282 by The GNUDist Company, "tgc" would be an appropriate choice for 283 "org". It's up to each organization to select an appropriate choice 284 for "name"; some organizations may use more structure than others, so 285 "name" may contain additional hyphens. 286 287 Suppose that The GNUDist Company was creating a branch to develop a 288 port of Binutils to the FullMonty processor. Then, an appropriate 289 choice of branch name would be: 290 291 binutils-tgc-fm 292 293 A date stamp is not required as part of the name field, but some 294 organizations like to have one. If you do include the date, you 295 should follow these rules: 296 297 1. The date should be the date that the branch was created. 298 299 2. The date should be numerical and in the form YYYYMMDD. 300 301 For example: 302 303 binutils-tgc-fm_20050101 304 305 would be appropriate if the branch was created on January 1st, 2005. 306 307 Having selected the branch name, create the branch as follows: 308 309 1. Check out binutils, so that you have a git checkout corresponding 310 to the initial state of your branch. 311 312 2. Create a tag: 313 314 git tag binutils-<org>-<name>-branchpoint 315 316 That tag will allow you, and others, to easily determine what's 317 changed on the branch relative to the initial state. 318 319 3. Create and push the branch: 320 321 git checkout -b binutils-<org>-<name>-branch 322 git push origin HEAD 323 324 4. Document the branch: 325 326 Add a description of the branch to binutils/BRANCHES, and check 327 that file in. All branch descriptions should be added to the 328 HEAD revision of the file; it doesn't help to modify 329 binutils/BRANCHES on a branch! 330 331 Please do not commit any patches to a branch you did not create 332 without the explicit permission of the person who created the branch. 333 335 Copyright (C) 2012-2025 Free Software Foundation, Inc. 336 337 Copying and distribution of this file, with or without modification, 338 are permitted in any medium without royalty provided the copyright 339 notice and this notice are preserved. 340
Indexes created Mon Jun 01 00:24:59 UTC 2026