有用的C语言工具
用于检查源代码的工具
工具 位于何处 所作工作
cb 随编译器附带 C程序美化器，在源文件中运行这个过滤器，可以使源文 件具有标准的布局和缩进格式。来自Berkeley
indent 与cb作用相同。来自AT&T
cdecl 本书 分析C语言的声明
cflow 随编译器附带 打印程序中调用者/被调用者的关系
cscope 随编译器附带 一个基于ASCII码C程序的交互式浏览器。我们在操作系统 小组中使用，用于检查头文件修改的结果。它提供了对下 列问题的快速答案：“有多少命令使用了libthread”或阅读了 kmem的所有文件是那些”
ctags /usr/bin 创建一个标签文件，供vi编译器使用。标签文件能加快程 序源文件的检查速度，方法使维护一个表，里面有绝大多 数对象的位置
lint 随编译器附带 C程序检查器
sccs /usr/ccs/bin 源代码版本控制系统
vgrind /usr/bin 格式器，用于打印漂亮的C列表
用于检查可执行文件的工具
工具 位于何处 所做工作
dis /usr/ccs/bin 目标代码反汇编工具
dump-Lv /usr/ccs/bin 打印动态链接信息
ldd /usr/bin 打印文件所需的动态
nm /usr/ccs/bin 打印目标文件的符号表
strings /usr/bin 查看嵌入于二进制文件中的字符串。用于查看二进制文件 可能产生的错误信息，内置文件名和（有时候）符号名或 版本和版权信息
sum /usr/bin 打印文件的检验和与程序块计数。回答下面这样的问题： “这些可执行文件是同一版本的吗？”“传输是否成功”
帮助调式的工具
工具 位于何处 所做工作
truss /usr/bin trace的SVr4版本，这个工具打印可执行文件所进行的系统 调用。它可用于查看 二进制文件正在干什么，以及为什么 阻塞或者失败。这将非常有用
ps /usr/bin 显示进程的特征
ctrace 随编译器附带 修改你的源文件，使文件执行时按行打印。是一个对小程序 非常有用的工具
debugger 随编译器附带 交互式调试器
file /usr/bin 告诉你的文件包含的内容（如可执行文件、数据、ASCII、 Shell脚本、archive等）
性能优化辅助工具
工具 位于何处 所做工作
collector 随编译器附带 （SunOS独有）在调试器控制下收集运行时性能数据
analyzer 随编译器附带 （SunOS独有）分析已收集的性能数据
gprof /usr/ccs/bin 显示调用图配置数据（确定计算密集的函数）
prof /usr/ccs/bin 显示每个程序所耗时间的百分比
tcov 随编译器附带 显示每条语句执行次数的计数（用于确定一个函数中计 算密集的循环）
time /usr/bin/time 显示程序所使用的实际时间和CPU时间
如果你工作于操作系统的内核模式，则无法使用绝大多数运行时工具，因为内核不像用户进程那样运行。可以使用编译时工具如lint，但除此之外我们只能使用石刀和燧斧了：将有序模式放入内存中，看看它们何时被覆盖（最常使用的两个是十六进制常量deadbeef和abadcafe），以及使用printf或类似的函数并记录跟踪信息。
用grep调试内核
当内核检测到“不会出现”的情况时，他就会“惊慌失措”，引起突然停止。
我们队伍中的两个顶尖工程师着手处理这个问题，他们注意到一个内存块的前19字节总是被涂抹。
这是一个不寻常的变异量，不像别处出现的2、4、8等常见值。其中一个工程师灵机一动。使用
这个偏移量来寻找这个bug。他建议用内核调试器kadb来反汇编内核二进制文件的映像（花了一小时时间），并将结果输出到一个ASCII文件中。然后用grep对这个文件进行搜索，寻找操作数偏移量为19的store指令。一共有8条这样的指令，它们都位于处理进程控制的子系统中。他们终于找到了罪魁祸首：位于一个进程控制结构中的竞争条件。它的用意是一个线程在其他线程（调用了该线程）真正完成工作之前现在内存中做个标记，以便以后返回系统。结果内核分配器把这块内存分配给了别人，但进程控制块仍以为它还保留有这块内存，所以向其写入，这样就导致了这个极难被发现的Bug。