Tag: gdb (subscribe)
GDB and SystemTap probes -- part 1
After a long time, here we are again :-).
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
Here's a simple example of an application with a one-argument probe:
1 2 3 4 5 6 7 8 9 10 11
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
1 2 3 4 5 6 7 8
(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 this
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 probein 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!
My workflow with GDB and git -- part 1
This post is actually a "reply" to Gary Benson's Working on gdb post.
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 did):
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
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
/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
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
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 :-).