This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[PATCH 0/3] Implement support for SystemTap probes on userspace
- From: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: gdb-patches at sourceware dot org
- Cc: Tom Tromey <tromey at redhat dot com>
- Date: Fri, 09 Mar 2012 17:28:51 -0300
- Subject: [PATCH 0/3] Implement support for SystemTap probes on userspace
Hello,
After a long time reworking the patches, I am finally resubmitting them
for review and, hopefully, inclusion.
This series of patches implement the support for SystemTap probes in
userspace on GDB. Not many people know, but SystemTap can be used to
insert and inspect probes on userspace applications as well (most people
use it in the kernel space), and those probes are simple markers on the
code which can be parsed by other programs. So this patch makes GDB
aware of those probes (and their arguments, when available) in a way
that the user will be able to inspect them while running the program.
The easiest way to insert a probe in your application is to include
<sys/sdt.h> (with systemtap-sdt-devel >= 1.4 on Fedora systems), and use
the STAP_PROBE* macros, e.g.:
#include <sys/sdt.h>
int
main ()
{
int a = 10;
STAP_PROBE1 (myprogram, myprobe, a);
exit (0);
}
After that, you can normally compile your code without the need of
special flags.
As you can see in the code above, the STAP_PROBE1 macro takes three
arguments: the first one is the provider (which in this case is just the
name of the program), the second is the probe name, and the third is the
first probe argument. If your probe doesn't need to have arguments, you
can use STAP_PROBE (which will take only the first two arguments), or if
your probe has more than one argument, you can use STAP_PROBE{1..12} and
specify up to twelve arguments. More information about probes on
userspace applications can be found at:
http://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps
Now, with the following patch, GDB will be able to recognize probes in
an objfile, and also evaluate the probe's argument(s). We have also
implemented the possibility put a tracepoint on a probe and collect its
argument(s).
When you start a patched GDB debugging a binary which contains probes in
it, you can get a list of the probes by using the new `info probes'
command:
sergio@psique ~/work/src/git/stap-patches/build-64/gdb $ ./gdb -q /tmp/stap-example
(gdb) info probes
Provider Name Where Semaphore Object
teste m4 0x0000000000400505 0x00000000006009f8 /tmp/stap-example
teste ps 0x00000000004004cd 0x00000000006009fc /tmp/stap-example
teste two 0x0000000000400484 0x00000000006009f6 /tmp/stap-example
teste two 0x0000000000400497 0x00000000006009f6 /tmp/stap-example
teste user 0x00000000004004ad 0x00000000006009f4 /tmp/stap-example
As you can see above, there are 5 probes in the binary. We can now ask
GDB to put a breakpoint in a probe, by using the new option `-p' or
`-probe' in the `break' command:
(gdb) b -probe m4
Breakpoint 1 at 0x400505
(gdb) run
Starting program: /tmp/stap-example
Breakpoint 1,
0x0000000000400505 in m4 (fs=0x7fffffffe300, v=0) at stap-probe.c:89
89 STAP_PROBE3 (teste, m4, fs->val, fs->ps (v), v);
This probe has 3 arguments, as we can see. But if we didn't have access
to the source code, we could inspect the number of arguments by printing
the new convenience variable `$_probe_argc':
(gdb) print $_probe_argc
$1 = 3
Now, suppose we want to evaluate the second argument, we would then
print the convenience variable `$_probe_arg1' (there are convenience
variables for $_probe_arg{0,..,11}):
(gdb) print $_probe_arg1
$2 = 4195944
And that's the main idea of the patch. Below, I will try to explain
what we did to achieve this.
The first patch of the series contains code to refactor the internal
variable mechanism, making it more OO and including new functions needed
to (for example) compile the internal variable to an agent expression.
The second patch contains the biggest part of the new work, with the
inclusion of new files such as stap-probe.[ch], responsible for parsing
and evaluating probes' arguments, and also for interfacing with external
requests from elfread.c and breakpoint.c. As mentioned above, I had to
write a parser for probe arguments, and I decided to use GDB's own
evaluation mechanism (using struct expression et al). We have also
included a couple of tests, documentation and new commands (like `break
[-p|-probe]'), and lots of code to support arch-dependent argument
parsing (please, review that for me). If you want to narrow your
review, I'd suggest starting here...
The third patch contains code to make use of the existing longjmp and
exception probes in glibc and libgcc, respectively. I believe Tom can
give more information about this patch, but the idea is that if we have
those probes available, GDB should use them because we don't need
debuginfo to access them.
This whole patch has been regtested on x86/x86_64 (no regressions), and
it has been tested on PPC/PPC64, ARM and S390.
Reviews are not just appreciated, but really wanted!
Thank you,
--
Sergio