Bug 907 - System call tracing
Summary: System call tracing
Status: RESOLVED DUPLICATE of bug 2111
Alias: None
Product: systemtap
Classification: Unclassified
Component: tapsets (show other bugs)
Version: unspecified
: P1 normal
Target Milestone: ---
Assignee: Kevin Stafford
URL:
Keywords:
Depends on: 1295 1336 1868
Blocks: 922
  Show dependency treegraph
 
Reported: 2005-04-29 20:13 UTC by E. Zannoni
Modified: 2006-01-28 19:07 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description E. Zannoni 2005-04-29 20:13:53 UTC
 
Comment 1 Frank Ch. Eigler 2005-09-13 18:21:05 UTC
high priority item, probably should be reassigned to kevin
Comment 2 Vara Prasad 2005-09-13 18:48:14 UTC
Kevin is working on System Call tapset now.
Comment 3 Frank Ch. Eigler 2005-09-26 16:21:37 UTC
Kevin, is there any reason you're not working on this tapset in the form of a
committed CVS file, so we can check your progress and test it as you go?
Comment 4 Kevin Stafford 2005-09-26 17:38:41 UTC
My bad Frank. I will commit the system call file today. Testing will be limited
however, contingent on BZ#1295. Also please see my posts about accessing args
from a return probe:

http://sourceware.org/ml/systemtap/2005-q3/msg00570.html
http://sourceware.org/ml/systemtap/2005-q3/msg00593.html

How do you think this scenario should be handled?
Comment 5 Kevin Stafford 2005-10-10 18:22:04 UTC
System calls prototyped, but untested. 
Comment 6 Frank Ch. Eigler 2005-11-08 16:49:27 UTC
Time to test them!
Add as many %( %? %) type conditionals as you need to make the following test
run on your kernel:

probe kernel.syscall.* { }
probe kernel.syscall.*.return { }

Comment 7 Kevin Stafford 2005-11-10 21:41:51 UTC
Great. Thanks Frank! The wildcard expansion seems to work.

This command 

stap -ve 'probe kernel.syscall.* { log ("Im a syscall!") }'

Results in this:

Pass 2: analyzed user script.  266 probe(s), 795 function(s), 0 global(s).
Pass 2: analysis failed.  Try again with '-v' (verbose) option.

It does not provide a reason for the failure, perhaps the ko is just too big to
compile. It does, however, seem to attempt to generate a module with probes on
every syscall - which is the expected behavior. It also seems to work fine with
a smaller test set.

One thing I noticed is...

stap -ve 'probe kernel.syscall.sys_w* { log ("Im a \"W\" syscall!") }'

fails with this message:

parse error: expected '.' or ',' or '(' or '{' or '='
        saw: operator '*' at <input>:1:27

So I suppose (right now) you can only use wildcards between the dot operators.
Although low priority, it may be nice to add the additional functionality to use
wildcards anywhere in the pattern.
Comment 8 Frank Ch. Eigler 2005-11-25 21:11:07 UTC
I see a bunch of other problems with CVS systemtap, RHEL4U3 alpha kernel, i686.
 Several $target variables still aren't accessible, and the translator can
sometimes SEGV for no good reason.  Do you not see such errors during your run?

Regarding more flexible wildcards for probe point components, I've opened bug #1928.
Comment 9 Frank Ch. Eigler 2005-11-25 21:12:54 UTC
By the way, if there is a failure in pass 2, the translator hasn't even started
writing out C code, so there exists no .ko that is potentially too big.
Comment 10 Frank Ch. Eigler 2005-11-28 01:26:05 UTC
Kevin, I remember you saying in a meeting recently that you have gotten the
entire system-call tapset to translate at one point, against some kernel.  When
was that, and against which kernel version?  Or do I misremember?
Comment 11 Kevin Stafford 2005-11-28 19:25:11 UTC
(In reply to comment #10)
> Kevin, I remember you saying in a meeting recently that you have gotten the
> entire system-call tapset to translate at one point, against some kernel.
[...]
Hi Frank. Sorry for the delayed response (gone for the holiday). Here is some info:

[krstaffo@localhost]$ uname -a
Linux 2.6.14 #1 SMP Thu Nov 10 10:49:16 PST 2005 i686 i686 i386 GNU/Linux

I saw some problems with the tapset that was in cvs. I made a few changes. This
compiles the module on my machine (if you have that latest syscall tapset): 
[krstaffo@localhost]$ stap -p4 -ve 'probe kernel.syscall.* {}'
[...]
TONS OF OUTPUT
[...]
Pass 4: compiled into "stap_XXXXX.ko"

However the module will not load: 
[krstaffo@localhost]$ stap -ve 'probe kernel.syscall.* {}'
[...]
TONS OF OUTPUT
[...]
ERROR: percpu context (size 154348) allocation failed

Comment 12 Frank Ch. Eigler 2005-11-28 19:33:13 UTC
OK, please commit your new tapset file when able.  If it needs %( %)
version-specific conditionals, so be it.

I'd appreciate seeing the generated C code (-p3) from that invocation.  Please
email it to me.  I am surprised that the context should be so large.

In any case, you should be able to make it go by adding a "-DMAXNESTING=10".
Comment 13 Kevin Stafford 2005-11-28 21:09:45 UTC
Some notes on my last update of system_calls.stp:

Reference to the (unsigned long) argument stack_start in the function clone,
fork, vfork generates this error: unable to find local 'start_stack', this may
be caused by BZ#1295.

Stap supports long long and string, so functions that accept other types for
there arguments will not compile: struct pt_regs in execve, union semun in semctl.

On i386, probe points could not be determined for pciconfig_iobase,
pciconfig_read, or pciconfig_write.
Comment 14 Frank Ch. Eigler 2006-01-28 19:07:41 UTC
baton handed to hunt

*** This bug has been marked as a duplicate of 2111 ***