Everyone of us has resorted at some point to printf-based debugging. Traces can be very useful, either because you want to see at a glance how a given value is changing over time or because stopping a thread at a breakpoint to examine some values can vanish the same race condition you are trying to debug. Nevertheless, inserting printf statements is a boring task, which makes you recompile everytime you want to change the set of values you want to see.

Ideally we could use tracepoints in our favorite debugger to collect some values and later dump them to a log, and gdb supports them but as the documentation points out:

The tracepoint facility is currently available only for remote targets. See Targets. In addition, your remote target must know how to collect trace data. This functionality is implemented in the remote stub; however, none of the stubs distributed with gdb support tracepoints as of this writing.

So, if our platform doesn’t support tracepoints… are we stuck with printf()? Well, yes and no. It turns out gdb allows us to specify actions to be executed at a breakpoint, so you can tell it to, every time it passes by some point in your program, print whatever you want and continue running. It’s not as good as the real deal, because a tracepoint would be more lightweight, but it can be helpful nonetheless.

Let’s see how to do it. Consider the following C program:

1
2
3
4
5
6
7
8
9
10

#include <stdio.h>
 
int main()
{
        int i;
        double x=2.0f;
        for (i=0; i<64; i++)
                x*=2;
        return 0;
}

if we compile it with debug info and launch it on gdb, we can log the values of x doing this:

(gdb) break 8
Breakpoint 1 at 0x400463: file a.c, line 8.
(gdb) commands 1
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>silent
>printf "x=%g\n",x
>cont
>end
(gdb) r
Starting program: /home/slack/a.out
x=2
x=4
x=8

The “silent” keyword as first action means that gdb shouldn’t print the info about the current stack frame it usually prints when stopping at a breakpoint, and the rest should be pretty self-explaining. In addition to gdb’s printf function you can also use more complex gdb expresions so you could, for instance, traverse a list and log its values or stuff like that :)

Happy coding!

I was curious if the GNU toolchain could do the same, and the answer is yes. According to the gdb documentation there are two ways of using debug info from another file:

• Adding a debug link to the executable file: create the binary with embedded debug information as usual, then copy it to another file, strip it out and add the debug link:

  objcopy --only-keep-debug program program.debug
  strip program
  objcopy --add-gnu-debuglink=program.debug program

  The debug link contains the file name, and a CRC of the full contents of the debug file. When loading the executable into gdb, it will look in program.debug and .debug/program.debug (paths relative to the executable file) for a file containing debug information. This method works with every executable format that can contain a section called .gnu_debuglink. I tested it on cygwin.

• Build ID: ld, the GNU linker, can embed a special section with a build identifier, which can be either a MD5 or SHA1 hash of the output file contents, a random number, or any given bitstring (see the documentation of the –build-id option). This ID will then be copied and preserved when a debug file is created or the binary is stripped. When a Build ID is present, gdb will try to load a debug file in /<debug-dir>/xx/yyyyyyyy.debug, where:- <debug-dir> is each directory specified with set debug-file-directory,- xxis the first byte of the hexadecimal Build ID bitstring, and- yyyyyyyy is the rest of the bitstring.

  This method is supported only on some platforms using ELF format for binaries and the GNU binutils.

Some days ago, while trying to show a colleague the benefits of a modern high-level language like Python over C++, I came up with the following snippet:

1
2
3
4
5
6
7

def memoize(fn):
     cache = {}
     def memoized_fn(*args):
         if args not in cache:
             cache[args] = fn(*args)
         return cache[args]
     return memoized_fn

It is a small function which takes a function as its only parameter, and returns a memoized version of that function. It is short, it shows some interesting Python features, like built-in dictionaries and tuples, or functions as first-class objects, and it should be pretty readable.

To make a fair comparison I needed to code a C++ version too. I was thinking about writing, just to prove my point, the classic boilerplate-filled template to create a function object, and using typelists and compile-time recursion to allow an arbitrary number of parameters. But it would have been quite boring. Also, it turns out that, with the upcoming C++ standard supporting lambda functions, tuples and variadic templates, it is possible to get rid of most of the boilerplate and use pretty much the same functional approach. Moreover, gcc 4.5 already supports these things, so I decided to give it a go:

1
2
3
4
5
6
7
8
9
10
11

template <typename ReturnType, typename... Args>
std::function<ReturnType (Args...)> memoize(std::function<ReturnType (Args...)> func)
{
    std::map<std::tuple<Args...>, ReturnType> cache;
    return ([=](Args... args) mutable  {
            std::tuple<Args...> t(args...);
            if (cache.find(t) == cache.end())                
                cache[t] = func(args...);
            return cache[t];
    });
}

Tricky things to note about the C++ version:

• The new lambda syntax: the equals sign in [=] means “capture local variables in the surrounding scope by value”, which is needed because we are returning the lambda function, and the local variable will disappear at that moment, so we can’t hold a reference to it. As we are capturing by value and we pretend to change this captured value, the function should be marked as mutable (see “Appearing and disappearing consts in C++” by Scott Meyers)
• Lambda functions are function objects of implementation-dependent type, so we need to use std::function as the return type from memoize() to wrap our lambda.

I still like the Python version better, as it looks cleaner to me, but I’m glad the new features can help us reduce the amount of boilerplate where switching to newer languages is not possible (sometimes you just NEED the extra speed). Kudos to the C++ standards committee for the improvements and the gcc team for keeping up with them.

EDIT (2011/03/21): Thanks everyone for the feedback, both in the comments here and in the reddit thread. Some additional notes:

• Here you have the complete sample file. I tested it under g++ 4.5.2 on MinGW, with -std=c++0x.
• This is a proof of concept, which I did to become familiar with the new language features. As some people pointed out, a map is not the best data structure to use as a cache (it has O(log n) lookups). You will probably do better if you use a hash map (like the new std::unordered_map in C++0x). I chose map just for the sake of clarity. Also, you will need to define an operator< for any type you would like to use (or a hash function for unordered_map).
• There were also suggestions to use lower_bound or equal_range to avoid the second map lookup and use the resulting iterator also as an insertion hint. I thought about saving the result in a local variable to avoid another lookup, but I wanted it to be as close as possible to the python version, just for clarity. I also didn’t know about these functions, so thanks for the tip! :D
• Some people also pointed out that this example doesn’t work with recursive functions. That’s completely true. In this post on stackoverflow the user larsmans suggests that I’m leaving the implementation of a fixed-point combinator as an exercise to the reader. Maybe it would be a good exercise for the writer, too… if I’m able to write something like that it will surely deserve its own post ;D

In the meantime, please check out the music section for some of my creations :)

Stay tuned!