From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123174 invoked by alias); 20 Jul 2015 17:54:47 -0000 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 Received: (qmail 123163 invoked by uid 89); 20 Jul 2015 17:54:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f53.google.com Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com) (74.125.82.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 20 Jul 2015 17:54:44 +0000 Received: by wgmn9 with SMTP id n9so136723277wgm.0 for ; Mon, 20 Jul 2015 10:54:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0MZ7O9W38Tkf74X6OTA6nt/jO272dnAUbjeZ+XimFSc=; b=XyeKvA/IhQoXvG/mFiubSkbxCrKZkCCvhhILiUslLrfk7DRVMwG08d4DZ1q4JubYQm 7wMjXIUC4OeABGLRl8opvvUy2pGTjaxjW55p9AbRN/bsuud1ciwKd2dFzc2PDrqd3nTm u/CNR/O4FerWe2B/Qd0AyLaORYNqtkhR75k2Q/I0wdZCJvBmAOFrVLBuI6lq4W8OHZRe m5v7Z/3+L0qlJhZpqSmDW2vXtAVCw6MMqibcoUyKHUwW20/aATm9FmQ9IRB95FO4/kU0 L2PKZIdtC7DW3TO7U1s5DWznFKtP6RIgwjmevoOezALmVIn6Da6FZ+hGxVEccPRu0hY8 hTRA== X-Gm-Message-State: ALoCoQnbAwd4R5Lqfel880WxgLsXtcz8G24zzgTK5zoHGdGfUBAZI+3asB3Z74QY0Rc/Glhte7pW X-Received: by 10.180.85.194 with SMTP id j2mr23503283wiz.11.1437414881488; Mon, 20 Jul 2015 10:54:41 -0700 (PDT) Received: from [192.168.0.101] ([90.152.119.35]) by smtp.googlemail.com with ESMTPSA id r19sm12886641wib.7.2015.07.20.10.54.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2015 10:54:40 -0700 (PDT) Message-ID: <55AD35DF.4010607@linaro.org> Date: Mon, 20 Jul 2015 17:54:00 -0000 From: Zoltan Kiss User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Josh Stone , systemtap@sourceware.org Subject: Re: process().statement() doesn't seem to work References: <558DA0E3.9060904@linaro.org> <5591D73E.3010309@redhat.com> In-Reply-To: <5591D73E.3010309@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-q3/txt/msg00041.txt.bz2 On 30/06/15 00:39, Josh Stone wrote: > On 06/26/2015 11:58 AM, Zoltan Kiss wrote: >> Hi, >> >> I want to use systemtap to figure out the local variables in a function >> where something goes fishy. The function's code is here: >> >> http://dpdk.org/browse/dpdk/tree/lib/librte_pmd_ixgbe/ixgbe_rxtx.c?id=v1.7.1#n1313 >> >> It's a receive function of DPDK's userspace poll mode driver, so it's >> called in an infinite loop. When I try this, it appers to work: >> >> probe >> process("/usr/sbin/ovs-vswitchd").function("ixgbe_recv_scattered_pkts").return >> { >> log($$locals) >> exit(); >> } >> >> The output is: >> >> rxq=0x7fff852ee000 rx_ring=? rxdp=? sw_ring=? rxe=? first_seg=? >> last_seg=? rxm=? nmb=? rxd={...} dma=? staterr=? hlen_type_rss=? rx_id=? >> nb_rx=0x0 nb_hold=0x0 data_len=? pkt_flags=? >> >> But it doesn't show most of the variables I need. It returns nb_rx=0, so >> I know where are the two points where things can go wrong, but I can't >> see the output of those variables (staterr and nmb) > > The behavior of .return variables is often suprising to people. By the > time a .return probe is reached, the program actually will have already > left that stack frame. Technically, that means only the $return value > is available to read. > > But we cheat a little and also save values from the *entry* of the > function for you. That's most useful for the $$parms string or any of > the individual parameters. > > Sometimes you can also get a glimpse of $$locals, if the debuginfo tells > us how, but again this is only from the very beginning of the function. > In your case, the three visible values all happen to have trivial > initialization: nb_rx = 0; nb_hold = 0; rxq = rx_queue; > > So you can't trust that these were still the values after the function > returned. For that, you really need to probe the statement just before > it actually returns. Even on the return statement itself is ok. Since > your function has just one return, it looks like line 1574 is best. > (but depending on optimizations, some locals might be missing there.) > >> When I try to define the probe as this: >> >> probe >> process("/usr/sbin/ovs-vswitchd").statement("*@lib/librte_pmd_ixgbe/ixgbe_rxtx.c:1359") >> >> Or with any line number inside that function, the probe is never >> reached. I'm using gcc 4.8.4, DPDK is statically linked to my application. >> Does anyone have an idea what might went wrong? > > It may be that you're really not reaching that line, e.g. if nb_pkts==0. > > You can see all the lines that stap can probe like this: > > stap -l 'process("/usr/sbin/ovs-vswitchd") > .statement("ixgbe_recv_scattered_pkts@*:*")' > > Or change -l to -L to also show all readable variables at each point. Thanks, I've figured out what I want in other ways. I'm still facing problems with stap, but let's start a different thread for that > > > You might like the varwatch example script: > > https://sourceware.org/systemtap/examples/#general/varwatch.stp > > It takes two arguments - first a probe pattern like your > process.statement wildcard, then the variable to watch like $$parms, > $$locals, or $$vars for both. A single name like $nb_rx is fine too. >