From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18664 invoked by alias); 3 Sep 2010 19:49:28 -0000 Received: (qmail 18656 invoked by uid 22791); 3 Sep 2010 19:49:26 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from e9.ny.us.ibm.com (HELO e9.ny.us.ibm.com) (32.97.182.139) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 03 Sep 2010 19:49:21 +0000 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o83JUsGY006862 for ; Fri, 3 Sep 2010 15:30:54 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o83JnGVa380918 for ; Fri, 3 Sep 2010 15:49:16 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o83JnFmh006429 for ; Fri, 3 Sep 2010 16:49:15 -0300 Received: from [9.47.18.61] (dyn9047018061.beaverton.ibm.com [9.47.18.61]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o83JnFdJ006377; Fri, 3 Sep 2010 16:49:15 -0300 Subject: Re: UProbes fails From: Jim Keniston To: Tim Beaulen Cc: systemtap@sources.redhat.com In-Reply-To: References: <1283498048.10596.2.camel@springer.wildebeest.org> Content-Type: text/plain; charset="UTF-8" Date: Fri, 03 Sep 2010 19:49:00 -0000 Message-ID: <1283543354.3253.28.camel@localhost> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2010-q3/txt/msg00361.txt.bz2 On Fri, 2010-09-03 at 20:27 +0200, Tim Beaulen wrote: > Looking at dmesg, I get this information: > > In 32-bit apps, uprobes does not currently support probing > instructions whose first byte is 0xf0 > Can't place uprobe at pid 4498 vaddr 0xb0bf9750: instruction type > cannot be probed > > This means I cant just do probe process("/some/process").function("*").call etc. > A little bit annoying, but absolutely not a problem, systemtap is > luckely flexible enough to work around it. 0xf0 is the lock prefix. As far as I know, we never enabled probing of instructions with the f0 prefix because we never got around to testing it. Will it work? I have no evidence either way. If you want to try it, I think all you need to do is this: # cd /usr/local/share/systemtap/runtime/uprobes (or wherever it is on your system) # Edit ../uprobes2/uprobes_x86.c In check_legacy_prefix(), move "case 0xf0:" to below the "return -1;" line. # rmmod uprobes.ko # make # insmod uprobes.ko (optional; stap will do this for you # stap ... ... and let us know what happens. Uprobes is outside my bailiwick now, so if that doesn't work, I can offer only limited support. Jim