Archive for Uncategorized

Enlarge your debugger

Sometimes my (amazing) coder friends and I organize a private informal conference/meeting, not unlike the small hacker meetings described in this post at hackerfactor.com, to talk about cool stuff we are doing lately. Last time was some weeks ago, and I gave a short talk about how you can use Python to extend and customize the functionality of gdb.

There is no recording of the talk, but you can read the slides. I hope you like them :D (Use left/right arrows to go to previous/next slide. In some slides you can also press down arrow to view “extra” slides with additional content, press the Escape key if you want to see which ones have extra slides.)

Comments off

Poor man’s tracepoints with gdb

(This article is an adaptation of this thing in Spanish I wrote in 2008. It’s nothing groundbreaking but a good friend of mine suggested a few days ago that it was still useful to him, so I decided to put it here. The new title is a reference to the poor man’s profiler, which you will probably like if you like this post)

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!

Comments off

How to use debug information in separate files with gdb

One of the things that surprised me when I started using Visual Studio, coming from a Linux programming background, was the amount of files it generates when you create and compile a project. One of these files is usually named project.pdb and contains the debug information for the final executable, along with information for incremental linking (Microsoft calls it the “program database“, hence the PDB extension). It turns out having separate debug information files can be useful when you want to distribute your program in binary form, but still be able to debug it when you get crash reports.

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.

Comments off

Welcome!

I’m currently moving here from my old website, so expect things to change or move around in the next days/weeks. I hope to move the music, demoscene productions and personal projects soon, but i still haven’t decided what to do with the posts in my old blog. Maybe I’ll import the posts, maybe I won’t.

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

Stay tuned!

Comments off