blog/content/posts/gdb-stap-linker-debugger.md

---
date: 2013-05-28T00:00:00-05:00
title: "GDB and SystemTap integration improving linker-debugger interface"
tags: [en_us, english, fedora-planet, gdb, systemtap, free-software]
---

It is really nice to see something you did in a project influence in
future features and developments. I always feel happy and proud when I
notice such scenarios happening, and this time was no different. [Gary
Benson](http://gbenson.net/), a colleague at Red Hat who works in the
GDB team as well, has implemented a way of improving the interface
between the linker and the debugger, and one of the things he used to
achieve this is the GDB <-> SystemTap integration that I
implemented with [Tom Tromey](http://tromey.com/) 2 years ago. Neat!

The problem
-----------

You can read a detailed description of the problem in [the message Gary
sent to the gdb-patches mailing
list](http://sourceware.org/ml/gdb-patches/2013-05/msg00624.html), but
to summarize: GDB needs to interface with the linker in order to
identify which shared libraries were loaded during the inferior's (i.e.,
program being debugged) life.

Nowadays, what GDB does is to put a breakpoint in `_dl_debug_state`,
which is an empty function called by the linker every time a shared
library is loaded (the linker calls it twice, once before modifying the
list of loaded shlibs, and once after). But GDB has no way to know what
has changed in the list of loaded shlibs, and therefore it needs to load
the entire list every time something happens. You can imagine how bad
this is for performance...

The solution
------------

What Gary did was to put SDT probes strategically on the linker, so that
GDB could make use of them when examining for changes in the list of
loaded shlibs. It improves performance a lot, because now GDB doesn't
need to stop twice every time a shlib is loaded (it just needs to do
that when `stop-on-solib-events` is set); it just needs to stop at the
right probe, which will inform the address of the link-map entry of the
first newly added library. It means GDB also won't need to walk through
the list of shlibs and identify what has changed: you get that for free
by examining the probe's argument.

Gary also mentions a discrepancy that happened on Solaris libc, which
has also been solved by his patch.

And now, the most impressing thing: the numbers! Take a look at this
table, which displays the huge improvement in the performance when using
lots of shlibs (the time is in *seconds*):

| Number of shlibs   | 128    | 256    | 512    | 1024    | 2048    | 4096    |
|--------------------|--------|--------|--------|---------|---------|---------|
| Old interface      | > 0    | > 1    | > 4    | > 12    | > 47    | > 185   |
| New interface      | > 0    | > 0    | > 2    | > 4     | > 10    | > 36    |

Impressive, isn't it?

Conclusion
----------

This is one the things I like most in Free Software projects: the
possibility of extending and improving things by using what others did
before. When I hacked GDB to implement the integration between itself
and SystemTap, I had absolutely no idea that this could be used for
improving the interface between the linker and the debugger (though I am
almost sure that Tom was already thinking ahead!). And I can say it is a
pleasure and I feel proud when I see such things happening. It just
makes me feel more and more certain that Free Software is the way to go
:-).