From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32752 invoked by alias); 28 Apr 2006 23:16:43 -0000 Received: (qmail 32745 invoked by uid 22791); 28 Apr 2006 23:16:42 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mga03.intel.com (HELO azsmga101-1.ch.intel.com) (143.182.124.21) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 28 Apr 2006 23:16:40 +0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101-1.ch.intel.com with ESMTP; 28 Apr 2006 16:16:38 -0700 Received: from scsmsx331.sc.intel.com (HELO scsmsx331.amr.corp.intel.com) ([10.3.90.4]) by azsmga001.ch.intel.com with ESMTP; 28 Apr 2006 16:16:38 -0700 X-IronPort-AV: i="4.04,165,1144047600"; d="scan'208"; a="29278728:sNHT20737808" Received: from scsmsx403.amr.corp.intel.com ([10.3.90.18]) by scsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Apr 2006 16:16:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Tapset difficulties w/ functions Date: Fri, 28 Apr 2006 23:16:00 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tapset difficulties w/ functions thread-index: AcZrGcw0gquvYn5QRg6Dmgx4J8alLg== From: "Stone, Joshua I" To: X-OriginalArrivalTime: 28 Apr 2006 23:16:37.0754 (UTC) FILETIME=[CC9885A0:01C66B19] X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q2/txt/msg00271.txt.bz2 Hi all, In working on the 'process' tapset, I've encountered a few difficulties that I thought I would share, so we can search the collective mind for solutions. I've split this into two emails to separate the related parts... For the process.exec probe, the best function I found is do_execve. However, I also need to cover compat_do_execve for the case where a 32-bit app execs on a 64-bit kernel. The compat variant is only present on 64-bit kernels where support for running 32-bit apps is enabled. I could make the inclusion of compat dependent on detecting a 64-bit architecture, as long as no one disables 32-bit support. Another option is to use a wildcard match, "*do_execve", and this will work great as long as the kernel never adds a new function that matches (prepare_to_do_execve, perhaps). A very clean solution I came up with requires tapset wildcards that ignore "missing" matches. We've discussed this before to make "syscall.*" easier, but that was decided against. However, here's another example of how this could make things very clean: probe process.exec =3D _process.exec.* { /* do stuff */ } probe _process.exec.part1 =3D kernel.function("do_execve") {} probe _process.exec.part2 =3D kernel.function("compat_do_execve") {} When the compat is missing, this would just continue silently with only do_execve. Another problem I have is with a signal handling probe - handle_signal seems perfect for this, except that on the 2096_FC5 kernel this function is inlined. It's not decorated 'inline', so apparantly the compiler just chose it for inlining. On RHEL4 it is not inlined. Without special-casing every kernel version in a macro, I don't see a way to detect this. One solution is to have a new dwarf-probe that will match both normal functions and inlines. I also want to show that tapset wildcards could solve this: probe process.signal.handle =3D _process.signal.handle.* { /* do stuff */ } probe _process.signal.handle.part1 =3D kernel.function("handle_signal") {} probe _process.signal.handle.part2 =3D kernel.inline("handle_signal") {} A similar mechanism could also be used to find functions that may have been compiled as a module by switching the parts on kernel.[...] and module("foo").[...] Josh