List of requirements for patches

See ContributionChecklist.

GDB Internals documentation

GDB has an official InternalsManual.

Jeremy Bennett wrote Howto: Porting the GNU Debugger, which is a good source of information as well. It is primarily aimed at engineers who will port GDB to a new target for the first time, but contains an overview of GDB Internals that is of general interest.

Creating ChangeLog entries

The GCC folks have a tool called mklog to help generate ChangeLogs. This script creates a ChangeLog template for a diff file. Run "mklog diff-file" and the template will be added to the top of the file.


After editing gdb/, you need to regenerate gdb/configure, gdb/ and gdb/aclocal.m4:

$ pwd
$ aclocal -I gnulib/m4
$ autoconf
$ autoheader

Please note:

Editing gdbarch.h/gdbarch.c

Don't. :-) These are generated files. Edit instead, and then run it.

See Internals Target-Architecture-Definition.

Updating GDB's import of gnulib

GDB now imports various modules from the gnulib project, located in gdb/gnulib. This import is used when building both GDB and GDBserver.

To facilitate the update of our import, a script called has been created to automate the process. To run this script:

    % cd /path/to/gdb-sources/gdb/gnulib
    % ./ /path/to/gnulib-git-repository

When run without change, the new import should be identical to the previous one. This is actually a good test to perform before making any update to our import, to make sure that everything is correctly setup.

The script maintains the two key pieces of information from which the import is created as constants defined inside the script:

When updating the import, please only modify one element at a time. For instance, if you want to import a new module only defined in a later version of gnulib, please first update the import to use the newer commit as a first patch, and then update the import to include the new module as a second patch.

Debugging gdbserver on uClinux / Linux with no MMU

GDB has issues with breakpoints set in gdbserver on !MMU targets. Ulrich Weigand has a tip to make it work:

Gdbserver uses a direct call to the Linux "clone" system call at startup,
and for some reason GDB gets really confused by this.

When I want to debug gdbserver, I generally simply comment out the call
to linux_test_for_tracefork in linux-nat.c:initialize_low to avoid this.

Writing testcases

See GDBTestcaseCookbook.

Finding Gnats bug entries in the Bugzilla database

If you ever had to find an old bug in the Bugzilla database, you probably stumbled upon this situation. There are some old entries from the now-retired Gnats database, which can be found by:

git hash mentioned in Bugzilla or mailing list discussion not found?

GDB used CVS as its main CSV up until October 2013, when it moved to git. The current git repository shares no ancestry with the old git mirror. The old git mirror is still available. See GitMirrors.

Making admin changes to bugzilla

Sometimes there's a need to add a new component, or make other admin changes to gdb's bugzilla. Send requests to Even gdb admins are not allowed admin access to this website (and those that have it work for Red Hat). Feel free to discuss requested changes on, but to put them into effect you have to talk to The Powers That Be.

You can also try #overseers on, but email is the official way.

Closing obsolete bugs

Bugzilla is (at least as of this writing) full of lots of old bugs that have too low a priority relative to everything else to put any time into. To improve the S/N ratio of bugs we do care about it's best to just close these old bugs out. The way to do this is to close them as RESOLVED/OBSOLETE. An example of this is here:

As for what the rules are that defines whether a bug falls into this category, good question.

Obviously build problems for gdb versions older than, say, 7.0, is pretty safe.

If possible (and relatively easy) you could try to reproduce the bug in git head, and if not reproducible, and if the gdb version in the bug report is older than 7.0, then the author thinks it's safe to close these out too.

Feel free to add comments to any PR asking whether the bug is old enough to close out. If such a question goes unanswered for a year, and the gdb version in the bug is older than, say, 7.0, then the author thinks it's safe to close these out too. A year may seem like a long time, but relative to how old some of the bugs are that need to be cleaned out, it's amply conservative and still useful.

The author thinks we could be slightly more aggressive with closing some of the older bugs. The above is intended to be a start.

Regenerating CGEN files

Here are the steps to regenerating the cgen files. Cgen is a tool for describing a cpu and then generating the opcodes and simulator files from that description.

No special configure options are needed, just --prefix.

bash$ cd /place/to/put/cgen
bash$ cvs -d co cgen

Make sure the build can find it.

bash$ ln -s $(pwd)/src/cgen $git/cgen

There's a TODO to be able to specify the path to cgen when configuring binutils,gdb. This step will go away, but until then.

This step will go away when some form of that patch is applied.

Generated files that need regenerating will be, including the opcodes files.

bash$ cd $build
bash$ $git/configure --prefix=$(pwd)/rel \
    --enable-cgen-maint \
    --enable-targets=all \
bash$ make all-sim

None: DeveloperTips (last edited 2022-03-11 13:13:31 by KevinLegouguec)

All content (C) 2008 Free Software Foundation. For terms of use, redistribution, and modification, please see the WikiLicense page.