Re: DTrace for Linux

[Kevin Stafford <kevinrs at us dot ibm dot com>]

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