Question

I have written a pretty-printer using the GDB Python interface for a (C) struct that has a tendency to change between software releases. Since the format is fluctuating I have tried to make the printer dynamic enough to adapt and always try to print something useful instead of throwing a Python exception.

Right now there are two major formats that I need to support but there is likely to be a few more in the future. I would like to write some unit tests for the printer to avoid having to manually load coredumps from different releases to test it.

I thought that maybe I could serialize the gdb.Value from within a debugging session and load them in my unit tests but I wasn’t able to do it (pickle didn’t work with gdb.Value). The core-dumps are really large so storing them with the pretty-printer and script GDB for the tests is not an option.

How can I unit-test my pretty printer without keeping huge core-dumps around?

Answer 1

How can I unit-test my pretty printer without keeping huge core-dumps around?

Keep small core dumps 🙂

Let’s assume you have struct Foo that you have a pretty printer for, and that keeps changing between releases.

Compile the following program:

#include <stdlib.h>
#include "foo.h"
int main()
{
   struct Foo f;
   // initialize f with some values
   abort();
}

Compile and run this program, store it and the resulting core as foo-v2 and foo-v2.core (assuming you are now on version 2 of the struct Foo). The core should be quite small.

Now checkout foo.h that corresponds to version 1 of struct Foo from your revision control system (you do use a revision control system, right?). Rebuild and re-run the program, store it as foo-v1 and foo-v1.core.

Now, with every release, you just have to rebuild/rerun above program, and compare output of GDB pretty printer with expected result. If it still works ok, you are done. If not, struct Foo must have changed, and you need to update your pretty printer.

Save the new binary and core as foo-v3 and foo-v3.core, update the pretty printer, then test it against all foo-vN and foo-vN.core pairs (for the test itself, use GDB unittesting framework that comes with GDB sources).