From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11845 invoked by alias); 17 Nov 2011 09:52:34 -0000 Received: (qmail 11824 invoked by uid 22791); 17 Nov 2011 09:52:33 -0000 X-SWARE-Spam-Status: No, hits=-7.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS 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; Thu, 17 Nov 2011 09:52:17 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pAH9qFmm027962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Nov 2011 04:52:15 -0500 Received: from springer.wildebeest.org (ovpn-116-27.ams2.redhat.com [10.36.116.27]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id pAH9qEf8028226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Nov 2011 04:52:15 -0500 Received: by springer.wildebeest.org (Postfix, from userid 500) id 5097E409C3; Thu, 17 Nov 2011 10:52:14 +0100 (CET) Subject: Re: Initial stap support for inode-based uprobes From: Mark Wielaard To: David Smith Cc: Josh Stone , systemtap@sourceware.org, Srikar Dronamraju In-Reply-To: <4EC3F556.4010902@redhat.com> References: <4DD5DEAA.3050908@redhat.com> <4EC3F556.4010902@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Nov 2011 09:52:00 -0000 Message-ID: <1321523534.3442.14.camel@springer.wildebeest.org> Mime-Version: 1.0 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: 2011-q4/txt/msg00187.txt.bz2 On Wed, 2011-11-16 at 11:39 -0600, David Smith wrote: > > * Probe IP. For many probe handlers, we try to set the pt_regs IP to > > the actual breakpoint IP, but in this case we don't happen to even know > > the virtualized address. Uprobes itself uses uprobes_get_bkpt_addr() in > > some instances, but that's not exposed for our use. This is really architecture dependent, we just currently do it by querying kprobes or uprobes where the breakpoint was set. On some architectures (x86 at least) the PC gets munged during the breakpoint processing (it is set after the breakpoint instruction on that architecture), which causes some confusion for some of the runtime or scripts which look at the REG_IP and see something different than they expect (in the worst case the PC is just after the current function or module). If you cannot get at the actual breakpoint address you will need to resort to architecture specific code, that know the breakpoint instruction used and how much the PC should be adjusted (normally the width of the breakpoint instruction). uprobe_stmt_num.exp and uprobe_uaddr.exp are the tests to look at. But also tests that do unwinding rely on REG_IP being somewhat sane. Cheers, Mark