(还没有评分)
Loading...由于DTrace probe在操作系统的kernel空间执行，所以不能直接访问进程user space的内容。通常要使用copyin、copyinstr这些函数把进程user space的内容copy出来。如果程序里的变量是个二级指针，就要相对麻烦一些。以下面程序为例（编译成32位的程序，所以指针用uint32_t）：
#include <stdio.h>
void func(char **p)
{
*p = strdup("hello");
return;
}
int main(void)
{
char *p[......]filebyproc.d位于DTraceToolkit的Proc文件夹下，其功能是打印进程打开的文件名。脚本代码就一行（略去版权信息）：
syscall::open*:entry { printf("%s %s", execname, copyinstr(arg0)); }
脚本代码分析如下：
监听所有open相关函数的entry probe，如果触发，就打印进程名（execname）和文件名（arg0）。
执行脚本，输出如下：
root# ./filebyproc.d
dtrace: script './filebyproc.d' matched 7 probes[......]kill.d位于DTraceToolkit的Proc文件夹下，其功能是检查进程之间发送的信号值，以及信号发送是否成功。脚本代码如下（略去版权信息）：
dtrace:::BEGIN
{
/* Print header */
printf("%5s %12s %5s %-6s %s\n",
"FROM", "COMMAND", "SIG", "TO", "RESULT");
}
syscall::kill:entry
{
/* Record target PID and signal */
self->target[......]
(还没有评分)Loading...如果要追踪程序的链接库的probe，可以参考下面这个例子：
bash-3.2# ldd ./exclude
libpthread.so.1 => /lib/libpthread.so.1
libodbc.so.2 => /usr/local/lib/libodbc.so.2
librt.so.1 => /lib/librt.so.1
libc.so.1 => /lib/libc.so.1
libiconv.so.2 => /u[......]
(还没有评分)Loading...CTF（Compact C Type Format）包含了下面信息：
a）所有类型和结构体的定义；
b）每个函数的参数和类型；
c）函数返回值的类型；
d）全局变量的类型。
因此如果有CTF数据，就可以有args[]变量信息。如何查看模块是否包含CTF数据？可以用以下命令：
bash# elfdump /lib/libc.so | grep SUNW_ctf
Section Header[37]: sh_name: .SUNW_ctf
如果模块有CTF数据，就会有这个section信息，反之则没有。