high priority item, probably should be reassigned to kevin
Kevin is working on System Call tapset now.
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?
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?
System calls prototyped, but untested.
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 { }
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.
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.
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.
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?
(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
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".
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.
baton handed to hunt *** This bug has been marked as a duplicate of 2111 ***