本文简单对比一下strace和ltrace的使用和输出信息。
首先编写一个简单的socket服务端和客户端，服务端用父进程来监听listenfd，将请求connfd交给fork出的子进程来处理，主要代码如下：
客户端主要代码如下：
strace和truss用来跟踪一个进程的系统调用或信号产生的情况，strace -f -o server.strace ./echoserver得到的服务端strace跟踪文件如下，除了socket相关的库函数（应用编程接口API）以外，还有其他很多系统调用以及SIGCHLD和SIGINT信号：
strace输出文件中，每一行都是一条系统调用，等号左边是系统调用的函数名及其参数，右边是该调用的返回值。truss、strace和ltrace的工作原理大同小异，都是使用ptrace系统调用来跟踪调试运行中的进程。
strace的trace日志分析：
1）每个item的格式为：进程号 系统调用（参数列表） = 返回值
2）文件描述符号：0是标准输入，1是标准输出，服务器端的3号是listenfd，4是接收到的第一个client的connfd。
而ltrace跟踪同样的程序，输出的信息则相对比较简单，只有库函数API和信号：
ltrace日志分析：
1）每个item的格式：进程号 库函数（参数列表） = 返回值
2）对比strace发现，应用程序调用stdio库的printf时，产生的系统调用fstat，mmap，write，最后是由write系统调用将字符串输出到标准输出。
3）应用程序调用库函数fork()来创建一个子进程，对应的系统调用时clone()，在strace中跟踪到的只有系统调用clone()。
库函数和系统调用的关系如下图：
对两种trace的额外开销做简单的分析：
在server端向client端发送消息的前后打上时间戳，即在write前后用gettimeofday记录开始时间和结束时间，timeval可以精确到微秒，比较不使用trace和使用trace的延时：
不输出到文件，直接在控制台输出的延时比输出到文件中略微低10微秒：
ltrace的开销要更大：
不输出到文件的延迟差不多也是200+微秒。