public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Zoltan Kiss <zoltan.kiss@linaro.org>
To: Josh Stone <jistone@redhat.com>, systemtap@sourceware.org
Subject: Re: process().statement() doesn't seem to work
Date: Mon, 20 Jul 2015 17:54:00 -0000	[thread overview]
Message-ID: <55AD35DF.4010607@linaro.org> (raw)
In-Reply-To: <5591D73E.3010309@redhat.com>



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.
>

      parent reply	other threads:[~2015-07-20 17:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-26 18:58 Zoltan Kiss
2015-06-29 23:39 ` Josh Stone
2015-07-09 14:49   ` Frank Ch. Eigler
2015-07-10 22:59     ` Josh Stone
2015-07-20 17:54   ` Zoltan Kiss [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55AD35DF.4010607@linaro.org \
    --to=zoltan.kiss@linaro.org \
    --cc=jistone@redhat.com \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).