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