我想在 Ubuntu 上使用 DTrace。

https://github.com/dtrace4linux/linux

上面有一个用于 Linux 的，github。

• 我想知道用于 linux 的 dtrace 是否与用于其他操作系统(Solaris、FreeBSD、OSX)的 dtrace 相同。
• 我想找一个使用这个(dtraceforlinux)的教程。
• 我想知道下面的 dtrace for solaris 教程是否适合我。

http://www.oracle.com/technetwork/server-storage/solaris/dtrace-tutorial-142317.html

最佳答案

作为dtrace4linux的作者，我来回答一下。

本质上，Linux/MacOS/FreeBSD/Solaris 上的 dtrace 是相同的——我们都基于相同的源代码和相同的目标。因为没有中央维护者，代码实际上是 fork 的，Solaris 被认为是主控。主要的源代码差异是每个平台的粘合剂。

DTrace 是多种事物的组合:

• 内核驱动程序
• 用户空间“dtrace”命令
• 探测功能机制(例如 syscall、fbt)
• 脚本语言

看看系统调用跟踪它非常简单:

$ dtrace -n syscall::open:
.....

这会捕获每个打开的系统调用，无论是谁执行的。如果你了解 Unix，你就会知道系统调用大约是:

open(char *filename, int flags, [int perms])

所以，arg0 是字符串“文件名”。但这就是不同的地方。 C lib 函数如上，但它映射到一个系统调用，类似于:

open(int someflags, char *filename, int userflags, int perms)

所以文件名不在 arg0 中，而是在 arg1 中。 (抱歉，如果上述错误 - 我认为 open() 在内核和用户空间中是相同的，但事实并非如此，例如对于 stat() 系列函数)。

这就是 DTrace 的一些“可移植性”问题出现的地方 - 如果您使用 dtrace 的 Solaris 指南，并尝试运行一些脚本或示例，您可能会发现它们的工作方式不同。理论上这是Linux(我)的错，应该修改dtrace4linux来隐藏这个。

这一切都适用于系统调用。

现在让我们看看 fbt。 Fbt 只是函数跟踪——任何函数——带有任何参数。您可以跟踪实现 open() 系统调用的 linux 函数(它称为 sys_open [可能])。如果你捕获这个函数:

$ dtrace -n fbt::sys_open:

那你得看内核源代码，看看arg0、arg1、arg2等是什么。几乎可以肯定，它与 Solaris 或 MacOS 不同——它的 Linux 实现细节。

但是你可能想要访问一些参数，例如获取一些内部内核数据结构(TCP、磁盘驱动程序、USB 驱动程序等)。 Solaris 提供了“提供者”，它们是访问数据结构的更高级别的方法，而不是知道“arg3 是'struct foo *'”。如果没有这些提供程序，脚本将完全依赖于 opsys，并且没有可移植性。大多数人并不关心“tcp”结构是什么样子，而是希望访问诸如 pktin、pktout、rcvbytes、sndbytes 等关键字段。

总结 dtrace4linux 和 Solaris dtrace 提供了一个可移植层以允许访问这些功能或结构，但是 dtrace4linux 或 Solaris 都没有尝试完成提供可移植性的工作跨越每个内核中的数千个结构。

一般来说，您可以使用 solaris 教程脚本并使用它们来尝试了解哪些不起作用，但是如果您不知道要查找什么，则尝试“按原样”使用它们会让您感到沮丧。

我认为 dtrace4linux “不错”和“不够好”以隐藏这些差异。 (dtrace4linux 与 MacOS 差不多——如果您使用 Solaris 教程，有些教程可能无法在 Mac 或 FreeBSD 上运行)。

https://stackoverflow.com/questions/14375364/