"付出努力的过程也许是举步维艰的，但必须是开心和充实的。“
----火星人
在挖掘工程代码的过程中，仅仅游走在header文件和源代码文件中往往是意犹未尽的感觉，尤其在实际环境中很难确定某一版本的开源代码真的就是当前系统运行的代码，反正无论怎样，对库文件的汇编追踪都是必不可少的。
汇编代码中的symbol追踪是非常重要的一环，一旦要对库函数做实验，编译测试代码，通过binary tool分析目标代码去hunt down真正的库函数细节！
此篇就是介绍在Mac OS X下这个过程的操作，let's do it.!
最近Mars在研究关于NaN的问题（Orz，写这篇的时候NaN的那篇还不到50%完成度，崩溃中......），那就用相关的代码来介绍一下吧！假设现在写下了下面个这个小羔羊程序：
#include <math.h> int main() { double d0 = nan("0xfff0000000001230"); return 0; }
这个程序的目标是追踪一下nan这个libc标准函数的实现，在库header里面大家是看不到他嘀～，因为他的实现代码是编译代码。
gcc -g -o nan nan.c
看一下编译后汇编代码的主体，因为没有-O选项，所以能看到没有任何优化的原貌：
_main: Leh_func_begin1: pushq %rbp Ltmp0: movq %rsp, %rbp Ltmp1: subq $16, %rsp Ltmp2: leaq L_.str(%rip), %rax movq %rax, %rdi callq _nan movsd %xmm0, -16(%rbp) movl $0, -8(%rbp) movl -8(%rbp), %eax movl %eax, -4(%rbp) movl -4(%rbp), %eax addq $16, %rsp popq %rbp ret Leh_func_end1:
从汇编码中看到了"callq _nan"，毫无挑战的行踪败露。下一步常规的手段可能会这样做：
otool -L nan
但这样的结果如下：
但事实上在/usr/lib/libSystem.B.dylib中根本不存在_nan的代码，只需要：
nm -a /usr/lib/libSystem.B.dylib | grep _nan
就可以知道：
完全没有，就算是存在符号连接也会被nm -a输出来的。
为什么会出现这么奇怪的情况，明明有外部符号，但otool输出的库缺没有这个外部符号的信息？这个问题目前还没找到答案，当另一种追踪符号的方法反而被脑补出来了。
因为下一步要gdb调试，所以带上-g，添加调试符号信息。OK~let's gdb it.
下面分别截图gdb的整个过程：
1）启动gdb看看代码
2）设置断点让程序运行，至于运行到哪里似乎没什么所谓（因为在实验中，把nan的调用嵌入到三重函数嵌套调用中，把断点设置在最外层函数调用之前，也同样可以），因为程序一旦开始执行，就会加载动态链接库的符号。
3）秘密武器出来～
在最后一步，通过info symbol nan就把这个未定义的外部符号最终归属给找出来了！！稍微检验一下：
nm -a /usr/lib/system/libmathCommon.A.dylib | grep "_nan"
搞定～找到～接下来就看_nan的代码吧！！
otool -p "_nan" -tV /usr/lib/system/libmathCommon.A.dylib
好啦，到这里已经完成对symbol追踪过程的阐述，也故意列出一些otool和nm的使用方法，希望大家受乐啦～毕竟Mac OS X下二进制文件的处理真不太方便，没有了objdump和readelf，虽然可以安装传说中的binutils，但一直没装上，Mars土鳖了。
转载于:https://www.cnblogs.com/mmars/archive/2013/05/21/3090502.html