From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10523 invoked by alias); 25 Mar 2010 07:35:44 -0000 Received: (qmail 10513 invoked by uid 22791); 25 Mar 2010 07:35:43 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,SARE_MSGID_LONG40 X-Spam-Check-By: sourceware.org Received: from mail-pv0-f175.google.com (HELO mail-pv0-f175.google.com) (74.125.83.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 25 Mar 2010 07:35:37 +0000 Received: by pvg13 with SMTP id 13so343378pvg.20 for ; Thu, 25 Mar 2010 00:35:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.13 with SMTP id v13mr1592428rvh.25.1269502535416; Thu, 25 Mar 2010 00:35:35 -0700 (PDT) In-Reply-To: <4B9F7B01.6030700@RedHat.com> References: <4B9648E4.2040706@RedHat.com> <4B96781B.2090801@redhat.com> <4B9F7B01.6030700@RedHat.com> Date: Thu, 25 Mar 2010 07:35:00 -0000 Message-ID: Subject: Re: Unresolved probes From: naresh kamboju To: Steve Dickson Cc: David Smith , SystemTAP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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-q1/txt/msg00771.txt.bz2 Hi, On Tue, Mar 16, 2010 at 6:05 PM, Steve Dickson wrote: > Sorry for the delayed response... > > On 03/09/2010 11:32 AM, David Smith wrote: >> On 03/09/2010 07:11 AM, Steve Dickson wrote: >>> Hello, >>> >>> I'm working the testsuite/buildok/nfs* and testsuite/buildok/rpc* >>> scripts and I'm running across a somewhat familiar problem where >>> certain routines are not resolvable. >>> >>> Using a "normal" 2.6.34 kernel I get the following errors: >>> >>> $ sudo ./run-stap -wp4 testsuite/buildok/rpc-all-probes.stp >>> semantic error: no match while resolving probe point module("sunrpc").f= unction("rpc_new_client").return >>> semantic error: no match while resolving probe point sunrpc.clnt.create= _client.return >>> semantic error: no match while resolving probe point module("sunrpc").f= unction("rpc_release_task").return >>> semantic error: no match while resolving probe point sunrpc.sched.relea= se_task.return >>> Pass 2: analysis failed. =A0Try again with another '--vp 01' option. I have also noticed same build error. >>> >>> Now when I use a 2.6.34 kernel compiled with the '-fno-inline-functions= -called-once' >>> flag (which turns off inline-ing when routines are called from only one= place) >>> the run-tap does not fail. And sure enough, both rpc_new_client() and >>> rpc_release_task() are only called from one place. >>> >>> So is there a work-around for this or should I just post the minor >>> changes I have and move on? >> >> I started looking into the same thing the other day. =A0I wondered: since >> those functions are only called from one place, why not just probe the >> caller? =A0In the case of 'rpc_new_client', the caller is 'rpc_create' (= in >> 2.6.34) or 'rpc_create_client' (in 2.6.18) > In theory this looks like it =A0will work but unfortunately the arguments= are > different so the really don't match up very well... Also probing the call= er > in the case of rpc_release_task() does not make sense since the caller > (i.e. __rpc_execute) is already probed... > >> >> The answer is probably just that the rpc tapset hasn't seen much work >> since 2007. > Good point... With this being the case, I'm going to suggest we just patc= h up > the rpc.stp with kernel_v clause so it works as it did with older kernels > and not break with new kernels. In the very near all this code will be > changing anyway with addition of nfsv4.1 so it probably makes sense to > patch and move on... > > So here is what I would like to do: > > commit ee6594700c8e259088bce82aa913cc2e951c7f69 > Author: Steve Dickson > Date: =A0 Tue Mar 16 08:23:14 2010 -0400 > > =A0 =A0The rpc buildok test suite probe breaks with new kernels > > =A0 =A0With newer kernels the rpc_release_task() routine is not defined > =A0 =A0because it becomes inline since its only called once. Plus the > =A0 =A0task allocation routines have changed so the arguments no longer > =A0 =A0match up with previous routines. So this patch uses the kernel_v > =A0 =A0clauses to allow the original functionality with older kernels > =A0 =A0and not to break on new kernels. > > =A0 =A0Signed-off-by: Steve Dickson > > diff --git a/tapset/rpc.stp b/tapset/rpc.stp > index d8f2fad..336cfcf 100644 > --- a/tapset/rpc.stp > +++ b/tapset/rpc.stp > @@ -121,14 +121,27 @@ probe _sunrpc.clnt.create_client.return.part1 =3D > =A0{ > =A0 =A0 =A0 =A0name =3D "sunrpc.clnt.create_client.return" > =A0} > -%) > - > =A0probe _sunrpc.clnt.create_client.return.part2 =3D > =A0 =A0 =A0 =A0kernel.function("rpc_new_client").return !, > =A0 =A0 =A0 =A0module("sunrpc").function("rpc_new_client").return > =A0{ > =A0 =A0 =A0 =A0name =3D "sunrpc.clnt.new_client.return" > =A0} > +%: > +probe _sunrpc.clnt.create_client.return.part1 =3D > + =A0 =A0 =A0 kernel.function("rpc_create").return !, > + =A0 =A0 =A0 module("sunrpc").function("rpc_create").return > +{ > + =A0 =A0 =A0 name =3D "sunrpc.clnt.create_client.return" > +} > +probe _sunrpc.clnt.create_client.return.part2 =3D > + =A0 =A0 =A0 kernel.function("rpc_create").return !, > + =A0 =A0 =A0 module("sunrpc").function("rpc_create").return > +{ > + =A0 =A0 =A0 name =3D "sunrpc.clnt.create_client.return" > +} > +%) > + > > =A0/* > =A0* Fires when the RPC client structure is to be cloned > @@ -722,14 +735,18 @@ probe sunrpc.svc.drop.return =3D kernel.function("s= vc_drop").return !, > =A0******************************************************************/ > =A0probe sunrpc.sched.entry =3D > =A0 =A0 =A0 =A0sunrpc.sched.new_task, > +%( kernel_v <=3D "2.6.18" %? > =A0 =A0 =A0 =A0sunrpc.sched.release_task, > +%) > =A0 =A0 =A0 =A0sunrpc.sched.execute, > =A0 =A0 =A0 =A0sunrpc.sched.delay > =A0{} > > =A0probe sunrpc.sched.return =3D > =A0 =A0 =A0 =A0sunrpc.sched.new_task.return, > +%( kernel_v <=3D "2.6.18" %? > =A0 =A0 =A0 =A0sunrpc.sched.release_task.return, > +%) > =A0 =A0 =A0 =A0sunrpc.sched.execute.return, > =A0 =A0 =A0 =A0sunrpc.sched.delay.return > =A0{} > @@ -777,6 +794,7 @@ probe sunrpc.sched.new_task.return =3D kernel.functio= n("rpc_new_task").return !, > =A0* @prot: =A0 =A0 =A0 =A0the IP protocol in the RPC call > =A0* @tk_flags: =A0 =A0the flags of the task > =A0*/ > +%( kernel_v <=3D "2.6.18" %? > =A0probe sunrpc.sched.release_task =3D kernel.function("rpc_release_task"= ) !, > =A0 =A0 =A0 =A0module("sunrpc").function("rpc_release_task") > =A0{ > @@ -796,6 +814,7 @@ probe sunrpc.sched.release_task.return =3D > =A0{ > =A0 =A0 =A0 =A0name =3D "sunrpc.sched.release_task.return" > =A0} > +%) > > =A0/* > =A0* Fires when the RPC `scheduler'(or rather, the finite state machine) > I have tested on arch: ARM kernel: 2.6.29-rt version: SystemTap-1.0/elfutils 0.143. glibc: 2.9 gcc version 4.3.3 The above patch is working fine. Thanks Steve. Best regards Naresh Kamboju