• DeveloperTips

List of requirements for patches

The file <gdb-src>/gdb/CONTRIBUTE contains instructions on what is expected from patches submitted to GDB. Please read through that document, and pay special attention to the Coding Standard and ChangeLog requirements.

GDB Internals documentation

GDB has an official Internals Manual (see the documentation page). It is a good reference guide for GDB, but some parts are incomplete or outdated.

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 mklog script creates a ChangeLog template for a diff file. This version was written by Diego Novillo and updated by Daniel Jacobowitz. Run "mklog diff-file" and the template will be added to the top of the file.

Editing configure.ac

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

$ pwd
/path/to/src/gdb
$ aclocal -I gnulib/m4
$ autoconf
$ autoheader

Please note:

• You need to use the correct versions of aclocal, autoconf and autoheader. The correct version is the one mentioned at the beginning of gdb/aclocal.m4 and gdb/configure.

• Don't include the changes to these generated files in your patch when you post it to the mailing list. These files are big and unnecessary for code review.

Patch Tracker

gdb has a patch tracker. Read here for instructions on how to use it.

Debugging gdbserver on Linux

GDB has issues with breakpoints set in gdbserver. 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

When adding a feature or fixing a bug which is not covered by the testsuite, you should write a new testcase or extend an existing one.

Here are some tips for writing a testcase:

• There are several convenience functions which perform common tasks in a GDB session. You can get a list of them with the command:

   grep '^proc' gdb/testsuite/libs/gdb.exp

• If you want to send a command to GDB without increasing the test count,

  use gdb_test with an empty message (i.e., pass an empty string as the third argument).

• When matching GDB output in a test, you have to wait for the prompt explicitly. If you ever leave expect in a state where two prompts should be arriving, it won't know which is which; if it sees them separately, you can get out of sync and all tests will fail with unknown output. This means your testcase will have a race condition and may pass or fail intermittently.

• gdb_test waits for the GDB prompt, gdb_test_multiple doesn't. When using the latter, you have to explicitly put the GDB prompt in your regular expressions.

• gdb_test puts and End-of-Line marker at the end of your regular expression.

• gdb_start_cmd doesn't do anything when running the test on a remote target (gdbserver, or a stub). It's probably better to avoid using it.