With this post I will start to talk about the integration between GDB
and SystemTap. This is something that Tom
Tromey and I did during the last year. The
patch is being reviewed as I write this post, and I expect to see it
checked-in in the next few days/weeks. But let’s get our hands dirty…
SystemTap Userspace Probes
You probably use (or have at least heard of) SystemTap, and maybe you
think the tool is only useful for kernel inspections. If that’s your
case, I have a good news: you’re wrong! You can actually use SystemTap
to inspect userspace applications too, by using what we call SDT
probes, or Static Defined Tracing probes. This is a very cheap
and easy way to include probes in your application, and you can even
specify arguments to those probes.
In order to use the probes (see an example below), you must include the
<sys/sdt.h> header file in your source code. If you are using Fedora
systems, you can obtain this header file by installing the package
systemtap-sdt-devel, version equal or greater than 1.4.
Here’s a simple example of an application with a one-argument probe:
As you can see, this is a very simple program with one probe, which
contains one argument. You can now compile the program:
Now you must be thinking: “Wait, wait… Didn’t you just forget to link
this program against some SystemTap-specific library or something?” And
my answer is no. One of the spetacular things about this
<sys/sdt.h> header is that it does not have any dependencies at all!
As Tom said in his blog post, this is
“a virtuoso display of ELF and GCC asm wizardy”.
If you want to make sure your probe was inserted in the binary, you can
use readelf command:
(I will think about writing an explanation on how the probes are laid
out on the binary, but for now you just have to care if you actually
see an output from thisreadelfcommand.)
You can also use SystemTap to perform this verification:
So far, so good. If you see an output like the one above, it means your
probe is correctly inserted. You could obviously use SystemTap to
inspect this probe, but I won’t do this right now because this is not
the purpose of this post.
For now, we have learned how to:
Include an SDT probe in our source code, and compile it;
Verify if the probe was correctly inserted.
In the next post, I will talk about the GDB support that allows you to
inspect, print arguments, and gather other information about
SDT probes. I hope you like it!
I have been working with GDB for quite some
time now, and even though the project officially uses
CVS (yes, you
read it correctly, it is CVS indeed!) as its version control system,
fortunately we also have a
git mirror. In the
end, what happens is that almost every developer uses the git mirror and
just goes to CVS to commit something. But this is another discussion.
Aside of this git mirror, we also have the
Archer repository (which
uses git by default).
My plan here is to show you how I do my daily work with GDB. The
workflow is pretty simple, but maybe you will see something here that
might help you.
Checking out the code
The first thing to do is to check out the code. I only have one GDB
repository here, and I make branches out of it whenever I want to hack.
So, to check out (or clone, in git’s parlance) the code, I do (or
With this, we have just cloned the GDB repository, and also added
another remote (i.e., repository). This is useful because we might want
to hack on a branch which is on Archer, but use GDB’s master branch
as a base.
Create a new branch for your work
So, now it’s time to create a new branch for you. Here I use one of my
little “tricks” (taught to me by my friend
Dodji), which is the command
git-new-workdir. This is a nice command because it creates a new
working directory for your project!
Maybe you’re wondering why this is so cool. Well, if you ever worked
with git, and more specifically, if you ever used more than one branch
at a time, then maybe you will understand my excitement. In this
scenario, having to constantly switch between the branches is not
something rare. When you have uncommited work in your tree you can
always use git stash, but that is not the ideal solution (for me).
Sometimes I would forget what was on the stash, and later when I checked
it, it was full of crap. Also, I like to have a separate directory for
every project I am working on.
It is also important to mention that git-new-workdir is under the
directory /usr/share/doc/git-VERSION/contrib/workdir/, so I created an
alias that will automagically call the script for me:
So, after setting up the script, here is what I do:
In order to build the project, I create a build-64 directory inside my
project directory (which, in the example above, is
GDB fortunately supports VPATH building (i.e., build the project outside
of the source tree). I strongly recommend you to use it.
As you may have noticed, I use -g3 (include debuginfo) and -O0 (do
not optimize the code) in CFLAGS. Also, since some of the features I
work on may affect code in other architectures, I use
--enable-targets=all. It will tell configure to compile everything
related to all architectures (not only x86_64, for example). At last,
I specify a separate debug directory which GDB should use to search for
Finalizing (for now)
After that, you will have a fresh GDB binary compiled in the build-64
directory. But that is not enough yet, since you will also want to test
GDB and make sure you didn’t insert a bug while hacking on it. In my
next post, I will explain what is my “testflow”. I hope it will be
useful for someone :-).