| 1 | |
| 2 | Contributing to GDB |
| 3 | |
| 4 | GDB is a collaborative project and one which wants to encourage new |
| 5 | development. You may wish to fix GDB bugs, improve testing, port GDB |
| 6 | to a new platform, update documentation, add new GDB features, and the |
| 7 | like. To help with this, there is a lot of documentation |
| 8 | available.. In addition to the user guide and internals manual |
| 9 | included in the GDB distribution, the GDB web pages also contain much |
| 10 | information. |
| 11 | |
| 12 | You may also want to submit your change so that can be considered for |
| 13 | conclusion in a future version of GDB (see below). Regardless, we |
| 14 | encourage you to distribute the change yourself. |
| 15 | |
| 16 | If you don't feel up to hacking GDB, there are still plenty of ways to |
| 17 | help! You can answer questions on the mailing lists, write |
| 18 | documentation, find bugs, create a GDB related website (contribute to |
| 19 | the official GDB web site), or create a GDB related software |
| 20 | package. We welcome all of the above and feel free to ask on the GDB |
| 21 | mailing lists if you are looking for feedback or for people to review |
| 22 | a work in progress. |
| 23 | |
| 24 | Ref: http://www.gnu.org/software/gdb/ |
| 25 | |
| 26 | Finally, there are certain legal requirements and style issues which |
| 27 | all contributors need to be aware of. |
| 28 | |
| 29 | o 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 | |
| 42 | o 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 | |
| 57 | o 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 | |
| 90 | Supplemental information for GDB: |
| 91 | |
| 92 | o 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 | |
| 100 | o 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 | |
| 111 | o 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 | |
| 118 | o 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 | |
| 126 | o 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 | |
| 133 | o 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. |