From: David Smith <dsmith@redhat.com>
To: David Wilder <dwilder@us.ibm.com>
Cc: Systemtap List <systemtap@sources.redhat.com>
Subject: Re: S390x - REL5 stap_testing_200611132049.results]
Date: Tue, 14 Nov 2006 19:47:00 -0000 [thread overview]
Message-ID: <455A17EC.8090002@redhat.com> (raw)
In-Reply-To: <455A14E2.3020901@us.ibm.com>
David Wilder wrote:
> David Smith wrote:
>
>>
>> Something *really* strange is going on there. The above output (and
>> the part that I cut out) shows that stap didn't do pass 4 for any of
>> the cache tests. That's really odd, since "stap -p4" is hardcoded in
>> that test.
>>
>> Can you run the following command *twice* and send me the output?
>>
>> # stap -v -p4 -e "probe begin {}"
>>
>> The output should look something like:
>>
>> ---------------
>> # stap -v -p4 -e "probe begin {}"
>> Pass 1: parsed user script and 53 library script(s) in
>> 140usr/10sys/165real ms.
>> Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0
>> global(s) in 10usr/10sys/3real ms.
>> Pass 3: translated to C into
>> "/tmp/stapGSMvEZ/stap_7a5fe045c67645c83d0df1d327d2de1c_122.c" in
>> 0usr/0sys/0real ms.
>> Pass 4: compiled C into "stap_7a5fe045c67645c83d0df1d327d2de1c_122.ko"
>> in 880usr/140sys/2566real ms.
>> # stap -v -p4 -e "probe begin {}"
>> Pass 1: parsed user script and 53 library script(s) in
>> 140usr/20sys/490real ms.
>> Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0
>> global(s) in 10usr/0sys/3real ms.
>> Pass 3: using cached
>> /home/dsmith/.systemtap/cache/7a/stap_7a5fe045c67645c83d0df1d327d2de1c_122.c
>>
>> Pass 4: using cached
>> /home/dsmith/.systemtap/cache/7a/stap_7a5fe045c67645c83d0df1d327d2de1c_122.ko
>>
>> ---------------
>>
> Pass 4 is giving an error, odd that it did not show up in the test
> log. Here it is:
> [....]
> mp/stapuYgXg9/.tmp_stap_9001.o /tmp/stapuYgXg9/stap_9001.c
> In file included from /usr/local/share/systemtap/runtime/runtime.h:79,
> from /tmp/stapuYgXg9/stap_9001.c:31:
> /usr/local/share/systemtap/runtime/alloc.c:66: error: expected
> declaration specifiers or '...' before '(' token
> /usr/local/share/systemtap/runtime/alloc.c: In function 'percpu_free':
> /usr/local/share/systemtap/runtime/alloc.c:67: error: number of
> arguments doesn't match prototype
> include/linux/percpu.h:51: error: prototype declaration
> [...]
>
> From runtime/alloc.c
> [...]
> #ifdef CONFIG_SMP
> [...]
> 66: void _stp_free_percpu(const void *objp)
> {
> int i;
> struct percpu_data *p = (struct percpu_data *) (~(unsigned long)
> objp);
>
> for_each_cpu(i)
> kfree(p->ptrs[i]);
> kfree(p);
> }
>
> But earler in alloc.c _stp_free_percpu() is defined:
>
> #ifdef CONFIG_SMP
> #define _stp_free_percpu(ptr) free_percpu(ptr)
> #else
> #define _stp_free_percpu(ptr) kfree(ptr)
> #endif
>
> I think the #ifdefs are messed up. Both defines are under CONFIG_SMP.
> If I comment out the first defines it works better, but I am still net
> seeing the
> "using cached " message.
>
> root@hez235 testing]# stap -v -p4 -e "probe begin {}"
> Pass 1: parsed user script and 52 library script(s) in
> 1410usr/90sys/1617real ms.
> Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 global(s) in
> 20usr/0sys/25real ms.
> Pass 3: translated to C into "/tmp/stapAeJiJi/stap_9300.c" in
> 780usr/2750sys/3863real ms.
> Pass 4: compiled C into "stap_9300.ko" in 9440usr/1950sys/12946real ms.
> [root@hez235 testing]# stap -v -p4 -e "probe begin {}"
> Pass 1: parsed user script and 52 library script(s) in
> 1410usr/90sys/1615real ms.
> Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 global(s) in
> 20usr/0sys/27real ms.
> Pass 3: translated to C into "/tmp/stapsDZD66/stap_9388.c" in
> 770usr/2760sys/4103real ms.
> Pass 4: compiled C into "stap_9388.ko" in 9470usr/1960sys/12527real ms.
>
Hmm. It appears from that output that the 'stap' binary you are using
doesn't have caching support. If it did, the name of the C file
wouldn't be 'stap_9388.c', it would be something like
'stap_6bc3d92354bbb164201d174128e2eca5_122.c'.
Can you check and ensure that the latest systemtap has been compiled and
installed? Let's see the output of "stap -V".
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
next prev parent reply other threads:[~2006-11-14 19:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-14 1:54 David Wilder
2006-11-14 16:58 ` David Smith
[not found] ` <4559F3FD.1000206@us.ibm.com>
2006-11-14 17:15 ` David Smith
2006-11-14 19:03 ` David Wilder
2006-11-14 19:47 ` David Smith [this message]
2006-11-14 20:00 ` David Wilder
2006-11-14 20:16 ` David Smith
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=455A17EC.8090002@redhat.com \
--to=dsmith@redhat.com \
--cc=dwilder@us.ibm.com \
--cc=systemtap@sources.redhat.com \
/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).