本文要介紹的ldd和nm是linux下，兩個用來分析程序很實用的工具。ldd是用來分析程序運行時需要依賴的動態庫的工具；nm是用來查看指定程序中的符號表相關內容的工具。下面通過例子，分別來介紹一下這兩個工具：
1. ldd, 先看下面的例子, 用ldd查看cs程序所依賴的動態庫：
在上面的例子中，ldd的結果可以分爲三列來看：
•第一列：程序需要依賴什麼庫
•第二列: 系統提供的與程序需要的庫所對應的庫
•第三列：庫加載的開始地址
通過上面的信息，我們可以得到以下幾個信息：
總結：
•（1） 通過對比第一列和第二列，我們可以分析程序需要依賴的庫和系統實際提供的，是否相匹配
A
該符號的值是絕對的，在以後的鏈接過程中，不允許進行改變。這樣的符號值，常常出現在中斷向量表中，例如用符號來表示各個中斷向量函數在中斷向量表中的位置。
B
該符號的值出現在非初始化數據段(bss)中。例如，在一個文件中定義全局static int test。則該符號test的類型爲b，位於bss section中。其值表示該符號在bss段中的偏移。一般而言，bss段分配於RAM中
C
該符號爲common。common symbol是未初始話數據段。該符號沒有包含於一個普通section中。只有在鏈接過程中才進行分配。符號的值表示該符號需要的字節數。例如在一個c文件中，定義int test，並且該符號在別的地方會被引用，則該符號類型即爲C。否則其類型爲B。
D
該符號位於初始話數據段中。一般來說，分配到data section中。例如定義全局int baud_table[5] = {9600, 19200, 38400, 57600, 115200}，則會分配於初始化數據段中。
G
該符號也位於初始化數據段中。主要用於small object提高訪問small data object的一種方式。
I
該符號是對另一個符號的間接引用。
N
該符號是一個debugging符號。
R
該符號位於只讀數據區。例如定義全局const int test[] = {123, 123};則test就是一個只讀數據區的符號。注意在cygwin下如果使用gcc直接編譯成MZ格式時，源文件中的test對應_test，並且其符號類型爲D，即初始化數據段中。但是如果使用m6812-elf-gcc這樣的交叉編譯工具，源文件中的test對應目標文件的test,即沒有添加下劃線，並且其符號類型爲R。一般而言，位於rodata section。值得注意的是，如果在一個函數中定義const char *test = “abc”, const char test_int = 3。使用nm都不會得到符號信息，但是字符串“abc”分配於只讀存儲器中，test在rodata section中，大小爲4。
S
符號位於非初始化數據區，用於small object。
T
該符號位於代碼區text section。
U
該符號在當前文件中是未定義的，即該符號的定義在別的文件中。例如，當前文件調用另一個文件中定義的函數，在這個被調用的函數在當前就是未定義的；但是在定義它的文件中類型是T。但是對於全局變量來說，在定義它的文件中，其符號類型爲C，在使用它的文件中，其類型爲U。
V
該符號是一個weak object。
W
The symbol is a weak symbol that has not been specifically tagged as a weak object symbol.
-
該符號是a.out格式文件中的stabs symbol。
?
該符號類型沒有定
1. ldd, 先看下面的例子, 用ldd查看cs程序所依賴的動態庫：
$ ldd cs
linux-gate.so.1 => (0xffffe000)
libz.so.1 => /lib/libz.so.1 (0xb7f8c000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7f75000)
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb7e4d000)
libpcre.so.0 => /usr/lib/libpcre.so.0 (0xb7e21000)
libstdc++.so.6 => /usr/local/gcc4.5.1/lib/libstdc++.so.6 (0xb7d40000)
libm.so.6 => /lib/libm.so.6 (0xb7d18000)
libgcc_s.so.1 => /usr/local/gcc4.5.1/lib/libgcc_s.so.1 (0xb7cfd000)
libc.so.6 => /lib/libc.so.6 (0xb7bbc000)
/lib/ld-linux.so.2 (0xb7fab000)
libdl.so.2 => /lib/libdl.so.2 (0xb7bb7000)在上面的例子中，ldd的結果可以分爲三列來看：
•第一列：程序需要依賴什麼庫
•第二列: 系統提供的與程序需要的庫所對應的庫
•第三列：庫加載的開始地址
通過上面的信息，我們可以得到以下幾個信息：
總結：
•（1） 通過對比第一列和第二列，我們可以分析程序需要依賴的庫和系統實際提供的，是否相匹配
•（2） 通過觀察第三列，我們可以知道在當前的庫中的符號在對應的進程的地址空間中的開始位置
2. nm, 通過下面的例子，我們來介紹nm工具：
先看一下這個簡單的程序：
#include "iostream"
using namespace std;
class Test
{
public:
void Hello()
{
cout < < "Hello world!" << endl;
}
};
int main()
{
Test test;
test.Hello();
}我們編譯該程序，然後看nm的結果：
$ g++ test.cc -o test
c$ nm test
08049f10 d _DYNAMIC
08049ff4 d _GLOBAL_OFFSET_TABLE_
080486f0 t _GLOBAL__I_main
080487fc R _IO_stdin_used
w _Jv_RegisterClasses
080486b0 t _Z41__static_initialization_and_destruction_0ii
0804870c W _ZN4Test5HelloEv
U _ZNSolsEPFRSoS_E@@GLIBCXX_3.4
U _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4
U _ZNSt8ios_base4InitD1Ev@@GLIBCXX_3.4
0804a040 B _ZSt4cout@@GLIBCXX_3.4
U _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_@@GLIBCXX_3.4
0804a0d4 b _ZStL8__ioinit
U _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@@GLIBCXX_3.4
08049f00 d __CTOR_END__
08049ef8 d __CTOR_LIST__
08049f08 D __DTOR_END__
08049f04 d __DTOR_LIST__
080488c8 r __FRAME_END__
08049f0c d __JCR_END__
08049f0c d __JCR_LIST__
0804a02c A __bss_start
U __cxa_atexit@@GLIBC_2.1.3
0804a024 D __data_start
080487b0 t __do_global_ctors_aux
08048610 t __do_global_dtors_aux
0804a028 D __dso_handle
w __gmon_start__
U __gxx_personality_v0@@CXXABI_1.3
080487aa T __i686.get_pc_thunk.bx
08049ef8 d __init_array_end
08049ef8 d __init_array_start
08048740 T __libc_csu_fini
08048750 T __libc_csu_init
U __libc_start_main@@GLIBC_2.0
0804a02c A _edata
0804a0d8 A _end
080487dc T _fini
080487f8 R _fp_hw
08048508 T _init
080485e0 T _start
0804a0cc b completed.7065
0804a024 W data_start
0804a0d0 b dtor_idx.7067
08048670 t frame_dummy
08048694 T main上面便是test這個程序中所有的符號，首先需要介紹一下上面的內容的格式：
•第一列：當前符號的地址
•第二列：當前符號的類型
•第三列：當前符號的名稱
在上面的結果中，像_ZN4Test5HelloEv這樣的符號，很多讀者朋友可能會被它搞暈，這裏介紹個小技巧，在nm的時候，加上-C選項，就可以把這些難以識別的符號，轉換成便於我們閱讀的符號TestHello()。這個主要是c++中的mangle機制所導致的，加上-C就是指定列出的符號是demangle了的。說了這麼多，到底nm對我們程序有啥具體的幫助呢，我覺得主要有以下幾個方面：
（1）判斷指定程序中有沒有定義指定的符號 (比較常用的方式：nm -C proc | grep symbol)
（2）解決程序編譯時undefined reference的錯誤，以及mutiple definition的錯誤
（3）查看某個符號的地址，以及在進程空間的大概位置（bss, data, text區，具體可以通過第二列的類型來判斷）
附：nm輸出中，部分符合類型說明 ，詳細見 nm 的幫助
A
該符號的值是絕對的，在以後的鏈接過程中，不允許進行改變。這樣的符號值，常常出現在中斷向量表中，例如用符號來表示各個中斷向量函數在中斷向量表中的位置。
B
該符號的值出現在非初始化數據段(bss)中。例如，在一個文件中定義全局static int test。則該符號test的類型爲b，位於bss section中。其值表示該符號在bss段中的偏移。一般而言，bss段分配於RAM中
C
該符號爲common。common symbol是未初始話數據段。該符號沒有包含於一個普通section中。只有在鏈接過程中才進行分配。符號的值表示該符號需要的字節數。例如在一個c文件中，定義int test，並且該符號在別的地方會被引用，則該符號類型即爲C。否則其類型爲B。
D
該符號位於初始話數據段中。一般來說，分配到data section中。例如定義全局int baud_table[5] = {9600, 19200, 38400, 57600, 115200}，則會分配於初始化數據段中。
G
該符號也位於初始化數據段中。主要用於small object提高訪問small data object的一種方式。
I
該符號是對另一個符號的間接引用。
N
該符號是一個debugging符號。
R
該符號位於只讀數據區。例如定義全局const int test[] = {123, 123};則test就是一個只讀數據區的符號。注意在cygwin下如果使用gcc直接編譯成MZ格式時，源文件中的test對應_test，並且其符號類型爲D，即初始化數據段中。但是如果使用m6812-elf-gcc這樣的交叉編譯工具，源文件中的test對應目標文件的test,即沒有添加下劃線，並且其符號類型爲R。一般而言，位於rodata section。值得注意的是，如果在一個函數中定義const char *test = “abc”, const char test_int = 3。使用nm都不會得到符號信息，但是字符串“abc”分配於只讀存儲器中，test在rodata section中，大小爲4。
S
符號位於非初始化數據區，用於small object。
T
該符號位於代碼區text section。
U
該符號在當前文件中是未定義的，即該符號的定義在別的文件中。例如，當前文件調用另一個文件中定義的函數，在這個被調用的函數在當前就是未定義的；但是在定義它的文件中類型是T。但是對於全局變量來說，在定義它的文件中，其符號類型爲C，在使用它的文件中，其類型爲U。
V
該符號是一個weak object。
W
The symbol is a weak symbol that has not been specifically tagged as a weak object symbol.
-
該符號是a.out格式文件中的stabs symbol。
?
該符號類型沒有定
