154 lines
5.4 KiB
Plaintext
154 lines
5.4 KiB
Plaintext
|
|
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://sourceware.cygnus.com/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.
|
|
http://www.gnu.ai.mit.edu/prep/standards_toc.html
|
|
Submissions which do not conform to the standards will be
|
|
returned with a request to reformat the changes.
|
|
|
|
For GDB, that standard is more tightly defined. GDB's
|
|
coding standard is determined by the output of
|
|
gnu-indent.
|
|
|
|
This situation came about because, by the start of '99,
|
|
GDB's coding style was so bad an inconsistent that it was
|
|
decided to restart things from scratch.
|
|
|
|
|
|
o Copyright Assignment
|
|
|
|
There are certain legal requirements
|
|
|
|
Before we can accept code contributions from you, we need a
|
|
copyright assignment form filled out.
|
|
|
|
If you've developed some addition or patch to GDB that you
|
|
would like to contribute, you should fill out a copyright
|
|
assignment form and send it in to the FSF. We are unable to
|
|
use code from you until this is on-file at the FSF, so get
|
|
that paperwork in! This form covers one batch of changes.
|
|
Ref: http://gcc.gnu.org/fsf-forms/assignment-instructions.html
|
|
|
|
If you think you're going to be doing continuing work on GDB, it
|
|
would be easier to use a different form, which arranges to
|
|
assign the copyright for all your future changes to GDB. It is
|
|
called assign.future. Please note that if you switch
|
|
employers, the new employer will need to fill out the
|
|
disclaim.future form; there is no need to fill out the
|
|
assign.future form again.
|
|
Ref: http://gcc.gnu.org/fsf-forms/assign.future
|
|
Ref: http://gcc.gnu.org/fsf-forms/disclaim.future
|
|
|
|
There are several other forms you can fill out for different
|
|
circumstances (e.g. to contribute an entirely new program, to
|
|
contribute significant changes to a manual, etc.)
|
|
Ref: http://gcc.gnu.org/fsf-forms/copyrights.html
|
|
|
|
Small changes can be accepted without a copyright assignment
|
|
form on file.
|
|
|
|
This is pretty confusing! If you are unsure of what is
|
|
necessary, just ask the GDB mailing list and we'll figure out
|
|
what is best for you.
|
|
|
|
Note: Many of these forms have a place for "name of
|
|
program". Insert the name of one program in that place -- in
|
|
this case, "GDB".
|
|
|
|
|
|
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 CVS repository at:
|
|
Cygnus, use "cvs update; cvs diff -c3p"; else, use "diff -c3p
|
|
OLD NEW" or "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.cygnus.com. All
|
|
patches and related discussion should be sent to the
|
|
gdb-patches mailinglist. For further information on the GDB
|
|
CVS repository, see the Anonymous read-only CVS access and
|
|
Read-write CVS 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.in'' 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.13 as of 2000-02-29).
|