GDB has a Bug
Database. It is used to track bugs (Problem Reports or PRs) and
enhancements (Change Requests or CRs). In addition to problems
encountered when running GDB, bugs include: errors or missing
documentation; missing test cases; web changes; work in progress;
dummy reports for fixed but unreported bugs; entries of not-a-bugs;
and even adminstrivia.
Please note that many companies now redistribute GDB, often as part of
a GNU/Linux distribution. When you find bugs in GDB that you
installed with a given GNU/Linux distribution, it is often useful to
first try reporting the bug directly to the distributor, not to us.
Sometimes, distributors have modified the GNU software (as they are
free to do so!) or they are running older versions. Thus, they may be
the best people to find a bug as it pertains to a particular
distribution.
Before submitting a new PR/CR, try browsing
the database to see if the problem has already been reported or even
fixed.
It is also very helpful if you can try reproducing the problem with a
current GDB snapshot (see current).
Often bugs in the most recent release (see download) have already been fixed in the latest
development sources. Regardless, be sure to fill in the
Release field.
The Bug Report Form has a number of fields, the intended use of some
of them are less than obvious, the below may help in filling in the
form:
CC these people on PR status e-mail
A list of
interested parties. If converting an e-mail posting into a bug report
consider including the CC line.
Category
Set this to GDB.
Synopsis
Since this is used for key word searches,
including the operating system (GNU/Linux, ...), compiler (GCC, xcc,
...) and language (C, C++, ...) can be helpful.
Confidential
Set this to no. GDB's bug
tracking database is not confidential.
Severity
How disastrous is the bug? The following
is a rule of thumb. critical: unusable (doesn't build, dumps
core during startup, ...), testsuite regression; serious: most
things (core dump, misleading behavour, ...); non-critical:
obscure edge condition.
Priority
From the viewpoint of the GDB, how urgent
is the bug fix? Select either medium or low.
High is reserved.
Submitter-Id
Set this to net.
Release
It appears as the first line of the GDB
startup text (GNU gdb 2002-03-01-cvs, GDB 4.17).
The more recent the release the better.
Environment
Three pieces of information are
useful:
the operating system verson (output of uname
-a)
the compiler version (for GCC, the output from
gcc -v)
how GDB was configured (the This GDB was
configured as line from GDB's startup text)
How-To-Repeat
A sequence (compiler invocation, gdb
commands, ...) that can be used to reproduce the problem. A new
testcase would be briliant!
When the GDB developers receive a bug report, we usually try to fix
the problem. While our bug fixes may seem like individual assistance,
they are not; they are part of preparing a new improved version. We
may send you a patch for a bug so that you can help us test the fix
and ensure its quality. If your bug report does not evoke a solution
from us, you may still get one from another user who reads our mailing
lists. Otherwise, use the GNU Service Directory
(a list of people who offer support and other consulting services).
If you're interested in participating in GDB's development (helping to
fix bugs, write documentation, develop new code), see the mailing list and contribute web pages.