1 2 Contributing to GDB 3 4GDB is a collaborative project and one which wants to encourage new 5development. You may wish to fix GDB bugs, improve testing, port GDB 6to a new platform, update documentation, add new GDB features, and the 7like. To help with this, there is a lot of documentation 8available.. In addition to the user guide and internals manual 9included in the GDB distribution, the GDB web pages also contain much 10information. 11 12You may also want to submit your change so that can be considered for 13conclusion in a future version of GDB (see below). Regardless, we 14encourage you to distribute the change yourself. 15 16If you don't feel up to hacking GDB, there are still plenty of ways to 17help! You can answer questions on the mailing lists, write 18documentation, find bugs, create a GDB related website (contribute to 19the official GDB web site), or create a GDB related software 20package. We welcome all of the above and feel free to ask on the GDB 21mailing lists if you are looking for feedback or for people to review 22a work in progress. 23 24Ref: http://www.gnu.org/software/gdb/ 25 26Finally, there are certain legal requirements and style issues which 27all contributors need to be aware of. 28 29o Coding Standards 30 31 All contributions must conform to the GNU Coding Standard. 32 Submissions which do not conform to the standards will be 33 returned with a request to reformat the changes. 34 35 GDB has certain additional coding requirements. Those 36 requirements are explained in the GDB internals documentation 37 in the gdb/doc directory. 38 39 Ref: http://www.gnu.org/prep/standards_toc.html 40 41 42o Copyright Assignment 43 44 Before we can accept code contributions from you, we need a 45 copyright assignment form filled out and filed with the FSF. 46 47 See some documentation by the FSF for details and contact us 48 (either via the GDB mailing list or the GDB maintainer that is 49 taking care of your contributions) to obtain the relevant 50 forms. 51 52 Small changes can be accepted without a copyright assignment form on file. 53 54 Ref: http://www.gnu.org/prep/maintain.html#SEC6 55 56 57o Submitting Patches 58 59 Every patch must have several pieces of information before we 60 can properly evaluate it. 61 62 A description of the bug and how your patch fixes this 63 bug. A reference to a testsuite failure is very helpful. For 64 new features a description of the feature and your 65 implementation. 66 67 A ChangeLog entry as plaintext (separate from the patch); see 68 the various ChangeLog files for format and content. Note that, 69 unlike some other projects, we do require ChangeLogs also for 70 documentation (i.e., .texi files). 71 72 The patch itself. If you are accessing the CVS repository use 73 "cvs update; cvs diff -cp"; else, use "diff -cp OLD NEW" or 74 "diff -up OLD NEW". If your version of diff does not support 75 these options, then get the latest version of GNU diff. 76 77 We accept patches as plain text (preferred for the compilers 78 themselves), MIME attachments (preferred for the web pages), 79 or as uuencoded gzipped text. 80 81 When you have all these pieces, bundle them up in a mail 82 message and send it to gdb-patches@sourceware.org. All 83 patches and related discussion should be sent to the 84 gdb-patches mailinglist. For further information on the GDB 85 CVS repository, see the Anonymous read-only CVS access and 86 Read-write CVS access page. 87 88-- 89 90Supplemental information for GDB: 91 92o Please try to run the relevant testsuite before and after 93 committing a patch 94 95 If the contributor doesn't do it then the maintainer will. A 96 contributor might include before/after test results in their 97 contribution. 98 99 100o For bug fixes, please try to include a way of 101 demonstrating that the patch actually fixes something. 102 103 The best way of doing this is to ensure that the 104 testsuite contains one or more test cases that 105 fail without the fix but pass with the fix. 106 107 People are encouraged to submit patches that extend 108 the testsuite. 109 110 111o Please read your patch before submitting it. 112 113 A patch containing several unrelated changes or 114 arbitrary reformats will be returned with a request 115 to re-formatting / split it. 116 117 118o If ``gdb/configure.in'' is modified then you don't 119 need to include patches to the regenerated file 120 ``configure''. 121 122 The maintainer will re-generate those files 123 using autoconf (2.13 as of 2000-02-29). 124 125 126o If ``gdb/gdbarch.sh'' is modified, you don't 127 need to include patches to the generated files 128 ``gdbarch.h'' and ``gdbarch.c''. 129 130 See ``gdb/configure.in'' above. 131 132 133o When submitting a patch that fixes a bug 134 in GDB's bug database a brief reference 135 to the bug can be included in the ChangeLog 136 vis 137 138 * CONTRIBUTE: Mention PR convention. 139 Fix PR gdb/4705. 140 141 The text ``PR gdb/4705'' should also be included 142 in the CVS commit message. That causes the 143 patch to automatically be archived with the PR. 144