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