[PATCH 0/3] Implement support for SystemTap probes on userspace

[Sergio Durigan Junior <sergiodj@redhat.com>]

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