From: "dsmith at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sourceware.org
Subject: [Bug translator/20307] tapset/linux/rpc.stp error
Date: Tue, 28 Jun 2016 18:13:00 -0000 [thread overview]
Message-ID: <bug-20307-6586-qc2Zvghh7C@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-20307-6586@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=20307
--- Comment #2 from David Smith <dsmith at redhat dot com> ---
Here's how __rpc_create_args is used (from tapset/linux/rpc.stp):
====
/*
* Newer kernels (> 2.6.18) compiled with gcc less than version
* 4.4.3-16, tend to have debuginfo that doesn't include location
* information for inline function arguments. This is a problem, since
* we need the arguments to rpc_new_client(), which is inline. Since
* we can't get them for those kernels, we stash (and delete) the value
* of the 'args' parameter of rpc_create(). We then use this value
* when probing the inline version of rpc_new_client() (if we don't
* have the real arguments to that inline function).
*/
@__private30 global __rpc_create_args
probe kernel.function("rpc_create").call !,
module("sunrpc").function("rpc_create").call ?
{
__rpc_create_args[tid()] = $args
}
probe kernel.function("rpc_create").return !,
module("sunrpc").function("rpc_create").return ?
{
delete __rpc_create_args[tid()]
}
====
First, let's see if those entry points exist:
====
# stap -L 'module("sunrpc").function("rpc_create").*'
module("sunrpc").function("rpc_create@net/sunrpc/clnt.c:489").call $args:struct
rpc_create_args* $xprtargs:struct xprt_create $servername:char[]
module("sunrpc").function("rpc_create@net/sunrpc/clnt.c:489").callee("xprt_create_transport@net/sunrpc/xprt.c:1297")
$args:struct xprt_create*
module("sunrpc").function("rpc_create@net/sunrpc/clnt.c:489").exported
$args:struct rpc_create_args* $xprtargs:struct xprt_create $servername:char[]
module("sunrpc").function("rpc_create@net/sunrpc/clnt.c:489").return
$return:struct rpc_clnt* $args:struct rpc_create_args* $xprtargs:struct
xprt_create $servername:char[]
====
So, the module version of those entry points do exist. Now let's see if those
lines are in the pass 1 output:
====
# stap -vp1 ../src/testsuite/buildok/rpc-all-probes.stp | fgrep
__rpc_create_args
%}global __rpc_create_args
(__args) = (__rpc_create_args[tid()]);
(__rpc_create_args[tid()]) = ($args);
delete __rpc_create_args[tid()];
Pass 1: parsed user script and 117 library scripts using
160640virt/43776res/8640shr/30592data kb, in 3230usr/80sys/3347real ms.
====
Yes, the lines are present. So, perhaps the optimizer has optimized the array
away - so let's try things unoptimized:
====
# stap -uvp2 ../src/testsuite/buildok/rpc-all-probes.stp
Pass 1: parsed user script and 117 library scripts using
160576virt/43648res/8576shr/30528data kb, in 2750usr/10sys/2960real ms.
WARNING: cannot probe .return of 1 inlined functions rpc_release_task
WARNING: cannot probe .return of 1 inlined functions rpc_release_task
WARNING: cannot probe .return of 1 inlined functions rpc_release_task
WARNING: cannot probe .return of 1 inlined functions rpc_release_task
WARNING: cannot probe .return of 1 inlined functions rpc_release_task
semantic error: unresolved arity-1 global array __rpc_create_args, missing
global declaration?: identifier '__rpc_create_args' at
/usr/local/share/systemtap/tapset/linux/rpc.stp:182:12
source: __args = __rpc_create_args[tid()]
^
semantic error: unresolved arity-1 global array __rpc_create_args, missing
global declaration?: identifier '__rpc_create_args' at :182:12
source: __args = __rpc_create_args[tid()]
^
semantic error: unresolved arity-1 global array __rpc_create_args, missing
global declaration?: identifier '__rpc_create_args' at :182:12
source: __args = __rpc_create_args[tid()]
^
semantic error: unresolved arity-1 global array __rpc_create_args, missing
global declaration?: identifier '__rpc_create_args' at :182:12
source: __args = __rpc_create_args[tid()]
^
semantic error: unresolved arity-1 global array __rpc_create_args, missing
global declaration?: identifier '__rpc_create_args' at :182:12
source: __args = __rpc_create_args[tid()]
^
semantic error: unresolved arity-1 global array __rpc_create_args, missing
global declaration?: identifier '__rpc_create_args' at :182:12
source: __args = __rpc_create_args[tid()]
^
semantic error: unresolved arity-1 global array __rpc_create_args, missing
global declaration?: identifier '__rpc_create_args' at :182:12
source: __args = __rpc_create_args[tid()]
^
semantic error: unresolved arity-1 global array __rpc_create_args, missing
global declaration?: identifier '__rpc_create_args' at :182:12
source: __args = __rpc_create_args[tid()]
^
semantic error: unresolved arity-1 global array __rpc_create_args, missing
global declaration?: identifier '__rpc_create_args' at :182:12
source: __args = __rpc_create_args[tid()]
^
Pass 2: analyzed script: 158 probes, 880 functions, 9 embeds, 1 global using
272896virt/158016res/10624shr/142848data kb, in 109990usr/2110sys/117436real
ms.
Pass 2: analysis failed. [man error::pass2]
====
Same exact errors.
More investigation will be needed.
--
You are receiving this mail because:
You are the assignee for the bug.
next prev parent reply other threads:[~2016-06-28 18:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-28 14:05 [Bug translator/20307] New: tapset/linux/rpc.stp error (possible because of 'private' keyword) dsmith at redhat dot com
2016-06-28 15:56 ` [Bug translator/20307] tapset/linux/rpc.stp error dsmith at redhat dot com
2016-06-28 18:13 ` dsmith at redhat dot com [this message]
2016-06-29 18:33 ` dsmith at redhat dot com
2016-06-29 18:34 ` [Bug translator/20307] 'private' on tapset global arrays causes errors dsmith at redhat dot com
2016-06-29 20:44 ` fche at redhat dot com
2016-06-30 15:11 ` mcermak at redhat dot com
2016-06-30 16:11 ` fche at redhat dot com
2016-07-01 7:31 ` mcermak at redhat dot com
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=bug-20307-6586-qc2Zvghh7C@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--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).