From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 404 invoked by alias); 9 Mar 2012 20:29:14 -0000 Received: (qmail 392 invoked by uid 22791); 9 Mar 2012 20:29:12 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_GJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 09 Mar 2012 20:28:56 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q29KSuLa020111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 9 Mar 2012 15:28:56 -0500 Received: from psique (ovpn-112-58.phx2.redhat.com [10.3.112.58]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q29KSpl1006614; Fri, 9 Mar 2012 15:28:53 -0500 From: Sergio Durigan Junior To: gdb-patches@sourceware.org Cc: Tom Tromey Subject: [PATCH 0/3] Implement support for SystemTap probes on userspace X-URL: http://www.redhat.com Date: Fri, 09 Mar 2012 20:29:00 -0000 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-03/txt/msg00353.txt.bz2 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 (with systemtap-sdt-devel >= 1.4 on Fedora systems), and use the STAP_PROBE* macros, e.g.: #include 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