public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* syscalltimes in examples
@ 2012-02-22 17:16 linxz02
  2012-02-22 17:54 ` David Smith
  0 siblings, 1 reply; 6+ messages in thread
From: linxz02 @ 2012-02-22 17:16 UTC (permalink / raw)
  To: systemtap

Hi All,

I'm using SystemTap-1.3. I was wondering whether I captured a bug in the example of syscalltimes.

When I run syscalltimes as it is, I see a bunch of errors saying unresolved types. It turned out that the following patch will work:

in around line 156:

# Check filters
if ('$FILTER') {
target = 0
++        if ('$F_UID') {
            if (pid() in f_pid) {
                timebypid[name, pid()] <<< delta
                target = 1
            }
++        }
++       if ('$F_PID') {
            if (uid() in f_uid) {
                timebyuid[name, uid()] <<< delta
                target = 1
            }
++      }
++        if ('$F_EXEC') {
            if (execname() in f_exec) {
                timebyexec[name, execname()] <<< delta
                target = 1
            }
 ++       }
} else
target = 1

I guess the trick is that, say, if !'$F_UID', earlier code that uses f_pid will be statically eliminated. Therefore stap compiler is confused by the appearance of f_pid here.

Thoughts? Thanks.

-Felix

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: syscalltimes in examples
  2012-02-22 17:16 syscalltimes in examples linxz02
@ 2012-02-22 17:54 ` David Smith
  2012-02-23  3:32   ` linxz02
  2012-02-23  5:00   ` linxz02
  0 siblings, 2 replies; 6+ messages in thread
From: David Smith @ 2012-02-22 17:54 UTC (permalink / raw)
  To: linxz02; +Cc: systemtap

On 02/22/2012 11:15 AM, linxz02@ovi.com wrote:

> Hi All,
> 
> I'm using SystemTap-1.3. I was wondering whether I captured a bug in the example of syscalltimes.


Version 1.3 is pretty old (it is from 2010-07-21).  The current version
is 1.7.  Is there any possibility of getting you to upgrade?

> 
> When I run syscalltimes as it is, I see a bunch of errors saying unresolved types. It turned out

> that the following patch will work:

... patch deleted ...

Which version of syscalltimes do you have, the one that might have come
with 1.3 or the current version?  Looks like Mark Wielaard updated this
script in Sep. 2011 to fix similar errors.  The following link contains
the latest version of the script:

<http://sourceware.org/systemtap/examples/process/syscalltimes>

The current version of the script works well with systemtap 1.7.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: syscalltimes in examples
  2012-02-22 17:54 ` David Smith
@ 2012-02-23  3:32   ` linxz02
  2012-02-23  7:52     ` Turgis, Frederic
  2012-02-23  5:00   ` linxz02
  1 sibling, 1 reply; 6+ messages in thread
From: linxz02 @ 2012-02-23  3:32 UTC (permalink / raw)
  To: David Smith; +Cc: systemtap

David,

Actually I was using syscalltimes from 1.3. I am running systemtap with the omap 2.6.35 kernel and it is suggested to use version 1.3 (http://omappedia.org/wiki/Systemtap#Systemtap_1.3_code_update_for_OMAP_ARM_platforms).

But I will definitely look at examples from 1.7 next time. Thanks very much for pointing out the right information.

-Felix



----- Original Message -----
> From: David Smith <dsmith@redhat.com>
> To: linxz02@ovi.com
> Cc: systemtap@sourceware.org
> Sent: Wednesday, February 22, 2012 11:54 AM
> Subject: Re: syscalltimes in examples
> 
> On 02/22/2012 11:15 AM, linxz02@ovi.com wrote:
> 
>>  Hi All,
>> 
>>  I'm using SystemTap-1.3. I was wondering whether I captured a bug in 
> the example of syscalltimes.
> 
> 
> Version 1.3 is pretty old (it is from 2010-07-21).  The current version
> is 1.7.  Is there any possibility of getting you to upgrade?
> 
>> 
>>  When I run syscalltimes as it is, I see a bunch of errors saying unresolved 
> types. It turned out
> 
>>  that the following patch will work:
> 
> ... patch deleted ...
> 
> Which version of syscalltimes do you have, the one that might have come
> with 1.3 or the current version?  Looks like Mark Wielaard updated this
> script in Sep. 2011 to fix similar errors.  The following link contains
> the latest version of the script:
> 
> <http://sourceware.org/systemtap/examples/process/syscalltimes>
> 
> The current version of the script works well with systemtap 1.7.
> 
> -- 
> David Smith
> dsmith@redhat.com
> Red Hat
> http://www.redhat.com
> 256.217.0141 (direct)
> 256.837.0057 (fax)
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: syscalltimes in examples
  2012-02-22 17:54 ` David Smith
  2012-02-23  3:32   ` linxz02
@ 2012-02-23  5:00   ` linxz02
  2012-02-23 16:34     ` Frank Ch. Eigler
  1 sibling, 1 reply; 6+ messages in thread
From: linxz02 @ 2012-02-23  5:00 UTC (permalink / raw)
  To: David Smith; +Cc: systemtap

Hello David,

It looked that syscalltimes from 1.7 eliminates most similar bugs but not all:

xzl@t500.felix-3[SystemTap-1.7]$ sudo ./syscalltimes -n com.android.browser
Creating and building SystemTap module...
Pass 1: parsed user script and 79 library script(s) using 16348virt/12488res/1676shr kb, in 110usr/20sys/133real ms.
semantic error: unresolved type : identifier 'f_pid' at <input>:66:16
        source:                 if (pid() in f_pid) {
                                             ^
semantic error: unresolved type : identifier 'f_uid' at :70:16
        source:                 if (uid() in f_uid) {
                                             ^
semantic error: unresolved type : identifier 'f_pid' at :4:16
        source: global f_exec, f_pid, f_uid
                               ^
semantic error: unresolved type : identifier 'f_uid' at :4:23
        source: global f_exec, f_pid, f_uid
                                      ^
Pass 2: analyzed script: 585 probe(s), 67 function(s), 25 embed(s), 11 global(s) using 148340virt/63120res/2664shr kb, in 1230usr/190sys/1424real ms.
Pass 2: analysis failed.  Try again with another '--vp 01' option.

Note that my line numbers here may not match the official version (http://sourceware.org/systemtap/examples/process/syscalltimes).Those errors are from function probe syscall.*.return().

To apply my modifications:

probe syscall.*.return {
# Skip if we have not seen this before
if (!([name, tid()] in starttime)) next

delta = gettimeofday_ns() - starttime[name, tid()]

# Check filters
if ('$FILTER') {
target = 0
        if ('$F_PID') {
    if (pid() in f_pid) {
    timebypid[name, pid()] <<< delta
    target = 1
    }
        }
        if ('$F_UID') {
    if (uid() in f_uid) {
    timebyuid[name, uid()] <<< delta
    target = 1
    }
        }
        if ('$F_EXEC') {
    if (execname() in f_exec) {
    timebyexec[name, execname()] <<< delta
    target = 1
    }
        }
} else
target = 1

.....

Now the scripts looks (partially?) OK:

xzl@t500.felix-3[SystemTap-1.7]$ sudo ./syscalltimes -n com.android.browser
Creating and building SystemTap module...
Pass 1: parsed user script and 79 library script(s) using 16252virt/12512res/1684shr kb, in 120usr/10sys/130real ms.
Pass 2: analyzed script: 585 probe(s), 39 function(s), 25 embed(s), 7 global(s) using 148516virt/63268res/2664shr kb, in 1170usr/230sys/1408real ms.
Pass 3: translated to C into "/tmp/stapqMiUrx/syscalltimes_src.c" using 148372virt/65512res/4968shr kb, in 170usr/60sys/235real ms.
syscalltimes.ko
Pass 4: compiled C into "syscalltimes.ko" in 16990usr/340sys/18079real ms.

Thanks very much.

-Felix

----- Original Message -----
> From: David Smith <dsmith@redhat.com>
> To: linxz02@ovi.com
> Cc: systemtap@sourceware.org
> Sent: Wednesday, February 22, 2012 11:54 AM
> Subject: Re: syscalltimes in examples
> 
> On 02/22/2012 11:15 AM, linxz02@ovi.com wrote:
> 
>>  Hi All,
>> 
>>  I'm using SystemTap-1.3. I was wondering whether I captured a bug in 
> the example of syscalltimes.
> 
> 
> Version 1.3 is pretty old (it is from 2010-07-21).  The current version
> is 1.7.  Is there any possibility of getting you to upgrade?
> 
>> 
>>  When I run syscalltimes as it is, I see a bunch of errors saying unresolved 
> types. It turned out
> 
>>  that the following patch will work:
> 
> ... patch deleted ...
> 
> Which version of syscalltimes do you have, the one that might have come
> with 1.3 or the current version?  Looks like Mark Wielaard updated this
> script in Sep. 2011 to fix similar errors.  The following link contains
> the latest version of the script:
> 
> <http://sourceware.org/systemtap/examples/process/syscalltimes>
> 
> The current version of the script works well with systemtap 1.7.
> 
> -- 
> David Smith
> dsmith@redhat.com
> Red Hat
> http://www.redhat.com
> 256.217.0141 (direct)
> 256.837.0057 (fax)
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: syscalltimes in examples
  2012-02-23  3:32   ` linxz02
@ 2012-02-23  7:52     ` Turgis, Frederic
  0 siblings, 0 replies; 6+ messages in thread
From: Turgis, Frederic @ 2012-02-23  7:52 UTC (permalink / raw)
  To: linxz02; +Cc: systemtap

Hi,

Note that we have moved internally to systemtap 1.6 on latest OMAP platforms, OMAP4 and OMAP5. v1.7 has just been tested for compilation, we will move after Mobile World Congress and update wiki page.
We moved at the same time to kernels 2.6.39/3.0/3.1 so we have not checked old kernel with newer systemtap.

Going to latest systemtap and kernel releases has brought even more stability on Android (Ubuntu did not have real issues). We don't know which of the 2 brought it.

Regards
Fred

OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement - System Multimedia

>
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----
> From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org] On Behalf Of
> linxz02@ovi.com
> Sent: Thursday, February 23, 2012 4:32 AM
> To: David Smith
> Cc: systemtap@sourceware.org
> Subject: Re: syscalltimes in examples
>
> David,
>
> Actually I was using syscalltimes from 1.3. I am running systemtap with the omap 2.6.35 kernel and it
> is suggested to use version 1.3
> (http://omappedia.org/wiki/Systemtap#Systemtap_1.3_code_update_for_OMAP_ARM_platforms).
>
> But I will definitely look at examples from 1.7 next time. Thanks very much for pointing out the right
> information.
>
> -Felix
>
>
>
> ----- Original Message -----
> > From: David Smith <dsmith@redhat.com>
> > To: linxz02@ovi.com
> > Cc: systemtap@sourceware.org
> > Sent: Wednesday, February 22, 2012 11:54 AM
> > Subject: Re: syscalltimes in examples
> >
> > On 02/22/2012 11:15 AM, linxz02@ovi.com wrote:
> >
> >>  Hi All,
> >>
> >>  I'm using SystemTap-1.3. I was wondering whether I captured a bug in
> > the example of syscalltimes.
> >
> >
> > Version 1.3 is pretty old (it is from 2010-07-21).  The current version
> > is 1.7.  Is there any possibility of getting you to upgrade?
> >
> >>
> >>  When I run syscalltimes as it is, I see a bunch of errors saying unresolved
> > types. It turned out
> >
> >>  that the following patch will work:
> >
> > ... patch deleted ...
> >
> > Which version of syscalltimes do you have, the one that might have come
> > with 1.3 or the current version?  Looks like Mark Wielaard updated this
> > script in Sep. 2011 to fix similar errors.  The following link contains
> > the latest version of the script:
> >
> > <http://sourceware.org/systemtap/examples/process/syscalltimes>
> >
> > The current version of the script works well with systemtap 1.7.
> >
> > --
> > David Smith
> > dsmith@redhat.com
> > Red Hat
> > http://www.redhat.com
> > 256.217.0141 (direct)
> > 256.837.0057 (fax)
> >

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: syscalltimes in examples
  2012-02-23  5:00   ` linxz02
@ 2012-02-23 16:34     ` Frank Ch. Eigler
  0 siblings, 0 replies; 6+ messages in thread
From: Frank Ch. Eigler @ 2012-02-23 16:34 UTC (permalink / raw)
  To: linxz02; +Cc: David Smith, systemtap

linxz02@ovi.com writes:

> [...]
> It looked that syscalltimes from 1.7 eliminates most similar bugs but not all:
> [...]

Good point.  I am going to merge a version of your suggested patch,
thanks!

But it seems like this script could be improved further.  Instead of
generating all the script code anew with various values of the F_*
strings, it could just pass those strings as overrides to the globals,
as in:

#  global f_exec_str, f_pid_str, f_uid_str
#  global filter_str
#  
#  probe begin { 
#        /* don't   if ('$F_EXEC') f_exec_str = ... */
#        /* tokenize f_exec_str */
#  }

In other words, don't include any '$FOO' substitutions inside the script
body.  Instead, pass them at run time like this:

#  stap -G f_exec_str='$F_EXECSTR' -G f_pid_str='$F_PIDSTR' ... the_script.stp

The resulting module would be fully cachable.

- FChE

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2012-02-23 16:34 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-22 17:16 syscalltimes in examples linxz02
2012-02-22 17:54 ` David Smith
2012-02-23  3:32   ` linxz02
2012-02-23  7:52     ` Turgis, Frederic
2012-02-23  5:00   ` linxz02
2012-02-23 16:34     ` Frank Ch. Eigler

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