72 lines
3.3 KiB
Markdown
72 lines
3.3 KiB
Markdown
---
|
|
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
|
|
:-).
|