GDB Testsuite Coding Standards

The GDB testsuite has historically had fewer rules than GDB itself. This has led to several "styles".

Plus there are occasions when a particular style is required by the test. GDB has to debug all different styles of code, and style can and has affected the debugging experience. The author recalls an issue regarding whether the opening { of a function is placed on the same line as the function name or on the next line.

The best guidance one can give is that unless a test requires a particular style (which is rare) you can't go wrong following the GDB coding standards. Failing that, cut-n-pasting from existing tests is typically OK, but see the rules below.

Rules For New Tests

Setting aside the various "styles" that appear in existing tests, there are a few (well, as of this writing one :-) ) rules for new tests.

In C code, don't use K&R function definitions

For example, write this

void
foo (void)
{
  /* blah */
}

Not this:

void
foo ()
{
  /* blah */
}

Don't include test directory name in test results

It's important that test results be comparable, run over run, and thus spurious differences need to be avoided. One possibly counter-intuitive source of spurious differences is the test directory name, even if relative: When the testsuite is run in parallel the test directory name is (essentially) machine-generated.

Here's an example: https://sourceware.org/ml/gdb-patches/2014-06/msg00519.html

None: Internals GDB-Testsuite-Coding-Standards (last edited 2014-07-07 20:35:43 by DougEvans)

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