DTrace for Linux

[Kevin Stafford]

Martin Hunt wrote:

>[...]
>Unfortunately it doesn't run of my x86_64 dev system, so I had
>to switch to an x86.
>[...]
>  
>
The syscall tapset has been tested on x86_64 with kernel 2.6.9-24.ELsmp.
I found that differences in architecture, kernel version, or 
configuration can
cause kernel.syscall.* { } to fail during compilation. The directory 
structure
has been altered in CVS to provide tapsets only for kernels & architectures
that I have successfully instrumented & tested.

>First thing I notice is that the tapset sets "name" to different values
>for the entry and exit probes. This makes matching them up a bit of a
>headache. So I edited the tapset and removed the ".return" on the values
>for "name" in the return probes. If no one has a reason why they should
>be there then we should make this change permanent.
>  
>
This is fine so long as probe alias wildcards are limited to expanding 
only within
the . (dot) characters. (See BZ # 1928)
For example: if kernel.syscall.* expands to all entry point aliases 
(kernel.syscall.*)
AND all return point aliases (kernel.syscall.*.return) then reference to 
"name"
would not differentiate between probes and return probes.

>Unfortunately, then I got an error on from the syscall tapset on
>execve.return.
>semantic error: no match for probe point
>         while: resolving probe point kernel.function
>("sys_execve").return
>
>So I commented out the whole sysexecve section in the tapset and tried
>again.
>  
>
This could be caused by the aforementioned differences in kernel 
version, arch,
or config options. More likely, this is due to the sys_execve.return 
being on the
translator blacklist. Jim submitted a patch that fixed the execve return 
probe issue.
(see http://sourceware.org/ml/systemtap/2005-q4/msg00223.html)

-- 
Kevin Stafford
DES 2 | MS 2M3
Beaverton - OR
Linux Technology Center
IBM Systems & Technology
Phone: 1-503-578-3039
Email: kevinrs@us.ibm.com