使用GDB调试RB-tree的几个问题
Content
0. 引子
1. 第1个例子
(1) at提示前半部分代表什么？
(2) at提示后半部分代表什么？
(3) 如果要阅读gcc的源代码，那么(2)中的文件在哪里？
2. 第2个例子
(1) 在gcc源代码中该函数在哪里？
(2) 为什么没有单步进入(step in)_Rb_tree_insert_and_rebalance函数？
(3) 该函数的实现在什么地方？即被编译进了哪个库？能否看到其信息？
(4) 如何单步调试关于红黑树的操作，例如左旋、右旋、平衡等(tree.cc中的函数)？
(4.1) 利用disassemble命令找到_Rb_tree_insert_and_rebalance的符号。
(4.2) 利用disassemble命令查看该函数的起始地址
(4.3) 在该函数中设置断点
3. 小结
(1) 本文使用的命令
(2) STL源代码位置
0. 引子
在Linux平台上开发C/C++程序，就免不了要使用GDB，当然你也可以使用DDD(Data Display Debugger)，关于DDD可以参考Appendix和官方网站，非本文重点，不做讨论。本文就使用GDB调试的过程中碰到的几个问题进行简单介绍。
1. 第1个例子
我们先看一个使用GDB调试的例子。
(gdb)
operator new (__p=0x8246018)
at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/new:94
94 inline void* operator new(std::size_t, void* __p) throw() { return __p; }
(gdb)
0x08049059 in __gnu_cxx::new_allocator::construct (this=0xbfca1b9f, __p=0x8246018,
__val=@0xbfca1cec)
at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/ext/new_allocator.h:104
104 { ::new(__p) _Tp(__val); }
(gdb)
~allocator (this=0xbfca1b9f)
at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/allocator.h:105
105 ~allocator() throw() { }
(gdb)
本文讨论的问题如下。
(1) at提示前半部分代表什么？
表示当前调用的代码所在的库的路径，即某个symbol存在于该路径下的某个库中。该例子指出当前调用的函数均存在于/usr/lib/gcc/i386-redhat-linux/4.1.2目录下的库文件中。例如，
# cd /usr/lib/gcc/i386-redhat-linux/4.1.2
# ls
crtbegin.o finclude libgcj.so libgfortran.so libstdc++.so
crtbeginS.o include libgcj.spec libgij.so libsupc++.a
crtbeginT.o libgcc.a libgcj-tools.so libgomp.a SYSCALLS.c.X
crtend.o libgcc_eh.a libgcov.a libgomp.so
crtendS.o libgcc_s.so libgfortran.a libgomp.spec
crtfastmath.o libgcj_bc.so libgfortranbegin.a libstdc++.a
# objdump -x libsupc++.a | grep new
new_handler.o: file format elf32-i386
rw-r--r-- 102/102 3564 Oct 21 23:42 2007 new_handler.o
8 .text._ZSt15set_new_handlerPFvvE 0000001f 00000000 00000000 00000060 2**4
13 .bss.__new_handler 00000004 00000000 00000000 00000120 2**2
00000000 l d .text._ZSt15set_new_handlerPFvvE 00000000 .text._ZSt15set_new_handlerPFvvE
00000000 l d .bss.__new_handler 00000000 .bss.__new_handler
00000000 g F .text._ZSt15set_new_handlerPFvvE 0000001f _ZSt15set_new_handlerPFvvE
00000000 g O .bss.__new_handler 00000004 __new_handler
RELOCATION RECORDS FOR [.text._ZSt15set_new_handlerPFvvE]:
00000014 R_386_GOT32 __new_handler
00000024 R_386_PC32 .text._ZSt15set_new_handlerPFvvE
new_op.o: file format elf32-i386
rw-r--r-- 102/102 2432 Oct 21 23:42 2007 new_op.o
00000000 *UND* 00000000 __new_handler
0000002d R_386_GOT32 __new_handler
new_opnt.o: file format elf32-i386
rw-r--r-- 102/102 2360 Oct 21 23:42 2007 new_opnt.o
00000000 *UND* 00000000 __new_handler
00000030 R_386_GOT32 __new_handler
new_opv.o: file format elf32-i386
rw-r--r-- 102/102 2100 Oct 21 23:42 2007 new_opv.o
new_opvnt.o: file format elf32-i386
rw-r--r-- 102/102 1608 Oct 21 23:42 2007 new_opvnt.o
14 .text.__cxa_vec_new2 000000c5 00000000 00000000 00000630 2**4
15 .text.__cxa_vec_new 00000053 00000000 00000000 00000700 2**4
16 .text.__cxa_vec_new3 000000cc 00000000 00000000 00000760 2**4
00000000 l d .text.__cxa_vec_new2 00000000 .text.__cxa_vec_new2
00000000 l d .text.__cxa_vec_new 00000000 .text.__cxa_vec_new
00000000 l d .text.__cxa_vec_new3 00000000 .text.__cxa_vec_new3
00000000 g F .text.__cxa_vec_new2 000000c5 __cxa_vec_new2
00000000 g F .text.__cxa_vec_new 00000053 __cxa_vec_new
00000000 g F .text.__cxa_vec_new3 000000cc __cxa_vec_new3
RELOCATION RECORDS FOR [.text.__cxa_vec_new2]:
RELOCATION RECORDS FOR [.text.__cxa_vec_new]:
00000049 R_386_PLT32 __cxa_vec_new2
RELOCATION RECORDS FOR [.text.__cxa_vec_new3]:
0000014c R_386_PC32 .text.__cxa_vec_new2
00000174 R_386_PC32 .text.__cxa_vec_new
00000194 R_386_PC32 .text.__cxa_vec_new3
# nm libsupc++.a | grep new
nm: eh_arm.o: no symbols
new_handler.o:
00000000 T _ZSt15set_new_handlerPFvvE
00000000 B __new_handler
new_op.o:
U __new_handler
new_opnt.o:
U __new_handler
new_opv.o:
new_opvnt.o:
00000000 T __cxa_vec_new
00000000 T __cxa_vec_new2
00000000 T __cxa_vec_new3
解析new_handler.o中的一个符号，
# c++filt _ZSt15set_new_handlerPFvvE
std::set_new_handler(void (*)())
该函数在new_handler.cc文件中的定义如下：
using std::new_handler;
new_handler __new_handler;
new_handler
std::set_new_handler (new_handler handler) throw()
{
new_handler prev_handler = __new_handler;
__new_handler = handler;
return prev_handler;
}
其中，new_handler在new文件中被定义，如下。
typedef void (*new_handler)();
另外，我们从makefile文件中也可以看到的确是以下5个关于"new"的.cc文件被编译。
new_handler.cc /
new_op.cc /
new_opnt.cc /
new_opv.cc /
new_opvnt.cc /
(2) at提示后半部分代表什么？
后半部分的提示表示当前代码执行到该文件，文件后面的数字表示行号。
../include只是表示在INCLUDE路径下，并没有指明是哪个include目录，可能是/usr/include，可能是/usr/local/include，也可能是第三方的某个include。
那么../include/c++/4.1.2/new文件具体在哪里？
笔者实验的Linux平台上，文件如下。
/usr/include/c++/4.1.2/new
/usr/include/c++/4.1.2/ext/new_allocator.h
/usr/include/c++/4.1.2/bits/stl_tree.h
(3) 如果要阅读gcc的源代码，那么(2)中的文件在哪里？
以上3个文件对应gcc的源代码，如下。
./libstdc++-v3/libsupc++/new
./libstdc++-v3/include/ext/new_allocator.h
./libstdc++-v3/include/bits/stl_tree.h (红黑树的实现就在这个文件中，该目录下以stl_开头的文件就是GCC使用的STL)
.表示gcc源代码目录，本文为E:/opensource/gcc-4.1.2。
2. 第2个例子
再看一个使用GDB单步运行的例子。
(gdb) step
std::_Rb_tree, std::less, std::allocator >::_M_insert (this=0xbfd33574, __x=0x0, __p=0xbfd33578, __v=@0xbfd3358c)
at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:817
817 _S_key(__p)));
(gdb) n
819 _Link_type __z = _M_create_node(__v);
(gdb)
821 _Rb_tree_insert_and_rebalance(__insert_left, __z, __p,
(gdb) step
823 ++_M_impl._M_node_count;
(gdb) l
818
819 _Link_type __z = _M_create_node(__v);
820
821 _Rb_tree_insert_and_rebalance(__insert_left, __z, __p,
822 this->_M_impl._M_header);
823 ++_M_impl._M_node_count;
824 return iterator(__z);
825 }
826
(gdb)
该例子要讨论的问题如下。
stl_tree.h第821行的_Rb_tree_insert_and_rebalance调用为什么没有step in(进入函数内部)？在Linux平台，该函数的实现在哪里？在gcc源代码中该函数在哪里？
我们先看该函数在gcc源代码中的位置。
(1) 在gcc源代码中该函数在哪里？
仔细查看gcc的源代码，我们发现，_Rb_tree_insert_and_rebalance函数的定义并不在str_tree.h中，而是在tree.cc文件中，位于./libstdc++-v3/src目录下，该目录下还有其他的pool_allocator.cc、mt_allocator.cc、list.cc等，其对应的头文件分别为：
./libstdc++-v3/include/ext/pool_allocator.h
./libstdc++-v3/include/ext/mt_allocator.h
./libstdc++-v3/include/std/std_list.h
对于list.cc需要解释一下。在list.cc文件中，直接#include ，但实际上，list文件在gcc的源代码包里是不存在的。那么包含list实际上是包含谁？我们在Linux系统中查看，list文件在/usr/include/c++/4.1.2目录中，如下。
# pwd
/usr/include/c++/4.1.2
# ls
algorithm clocale ctime functional java ostream typeinfo
backward cmath cwchar gcj javax queue utility
bits complex cwctype gnu limits set valarray
bitset csetjmp cxxabi.h i386-redhat-linux list sstream vector
...
打开list文件，其内容如下，这个标准的头文件实际上就是包含stl_list的定义文件stl_list.h及其需要的其他头文件，如allocator.h等。
60 #ifndef _GLIBCXX_LIST
61 #define _GLIBCXX_LIST 1
62
63 #pragma GCC system_header
64
65 #include
66 #include
67 #include
68 #include
69 #include
70 #include //stl list的定义文件
71
72 #ifndef _GLIBCXX_EXPORT_TEMPLATE
73 # include //stl list的某些模板成员函数的实现文件
74 #endif
75
76 #ifdef _GLIBCXX_DEBUG
77 # include
78 #endif
对应于gcc源代码，安装到Linux系统中的list文件实际上就是./libstdc++-v3/include/std/std_list.h文件，只是在安装到时候将其改名并拷贝到/usr/include/c++/4.1.2目录。同样的道理也适用于STL其他的container，如vector，set，deque，map，stack，queue等。所以我们使用STL编写代码时，包含的文件是，，等，而非, , 。
以下是readme文件中对./libstdc++-v3/include/std和./libstdc++-v3/src目录下的文件的解释。
include/std
Files meant to be found by #include directives in
standard-conforming user programs.
src
Files that are used in constructing the library, but are not
installed.
问题扯远了，我们回到要讨论的问题。
(2) 为什么没有单步进入(step in)_Rb_tree_insert_and_rebalance函数？
要想step in某个函数，一定要有相应的源代码的文件，很显然，该函数所在的文件tree.cc在Linux系统里并不存在。那如果我们希望单步进入该函数，可能需要重新编译gcc源代码并将所有.h和.c/.cc/.cpp的文件都安装到相应的目录下。例如在笔者的虚拟机里，调试ACE的程序，都可以进入ACE源代码内部进行。但从上述对./libstdc++-v3/src目录下的文件的解释可以看出，在Linux系统上并不安装这些.cc文件，因此，要单步调试这些程序，貌似很困难。但也不是没有方法，我们稍后讨论。
那么，
(3) 该函数的实现在什么地方？即被编译进了哪个库？能否看到其信息？
摘_Rb_tree_increment函数的代码，如下。
namespace std
{
_Rb_tree_node_base*
_Rb_tree_increment(_Rb_tree_node_base* __x)
{
if (__x->_M_right != 0)
{
__x = __x->_M_right;
while (__x->_M_left != 0)
__x = __x->_M_left;
}
else
{
_Rb_tree_node_base* __y = __x->_M_parent;
while (__x == __y->_M_right)
{
__x = __y;
__y = __y->_M_parent;
}
if (__x->_M_right != __y)
__x = __y;
}
return __x;
}
...
}
其参数_Rb_tree_node_base定义如下，
struct _Rb_tree_node_base
{
typedef _Rb_tree_node_base* _Base_ptr;
typedef const _Rb_tree_node_base* _Const_Base_ptr;
_Rb_tree_color _M_color;
_Base_ptr _M_parent;
_Base_ptr _M_left;
_Base_ptr _M_right;
...
};
很显然，该函数是属于std空间的一个全局函数，不是类的成员函数，也不是模板函数，其参数_Rb_tree_node_base也不是模板类。tree.cc中的9个函数均是这样，且在每个函数内部，只是对指针的操作，不涉及定义一个对象(编译时需要分配逻辑地址，占虚拟空间)，或者使用new/delete操作符，因此所有这些函数(tree.cc文件)在编译期间不需要确定一些数据类型，gcc在编译时便将其编译到了静态库libstdc++.a中(tree.cc的目标文件为tree.o)，使用时再链接到目标可执行文件。
实际上，可以认为tree.cc文件(9个函数)是一个独立的小模块，而且是一个独立性很强的模块，_Rb_tree_node_base的改变(即stl_tree.h的改变)不会影响tree.cc。像这样的模块，应该做成静态库供用户使用，从而减少编译依赖和时间。
可以通过如下命令查看静态库libstdc++.a中的关于RBtree的操作信息。
# cd /usr/lib/gcc/i386-redhat-linux/4.1.2 //以下要解析的库在该目录
# nm libstdc++.so //libstdc++.so是动态库，其中没有symbols
nm: libstdc++.so: no symbols
# nm libstdc++.a | grep _Rb_tree_
00000000 T _ZSt18_Rb_tree_decrementPKSt18_Rb_tree_node_base
00000000 T _ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base
00000000 T _ZSt18_Rb_tree_incrementPKSt18_Rb_tree_node_base
00000000 T _ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base
00000000 T _ZSt20_Rb_tree_black_countPKSt18_Rb_tree_node_baseS1_
00000000 T _ZSt20_Rb_tree_rotate_leftPSt18_Rb_tree_node_baseRS0_
00000000 T _ZSt21_Rb_tree_rotate_rightPSt18_Rb_tree_node_baseRS0_
00000000 T _ZSt28_Rb_tree_rebalance_for_erasePSt18_Rb_tree_node_baseRS_
00000000 T _ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_
nm: stubs.o: no symbols
nm: eh_arm.o: no symbols
# c++filt _ZSt18_Rb_tree_decrementPKSt18_Rb_tree_node_base
std::_Rb_tree_decrement(std::_Rb_tree_node_base const*)
# c++filt _ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base
std::_Rb_tree_decrement(std::_Rb_tree_node_base*)
# c++filt _ZSt28_Rb_tree_rebalance_for_erasePSt18_Rb_tree_node_baseRS_
std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*, std::_Rb_tree_node_base&)
以上通过c++filt命令解析的符号便是./libstdc++-v3/src/tree.cc文件中的函数，其他的符号，读者可自行试验，也是tree.cc中的函数。
由以上信息可知，该函数被编译进了libstdc++.a这个静态库中。通过如下命令，可以得知tree.cc编译后的目标文件tree.o的确被打包进了静态库libstdc++.a。
# cd /usr/lib/gcc/i386-redhat-linux/4.1.2
# mkdir test //建立一个试验目录，试验完后容易删除
# cp libstdc++.a test/libstdc++.a
# cd test
# ls
libstdc++.a
# ar -x libstdc++.a //extract file(s) from the archive
# ls //所有.o文件便是从静态库libstdc++.a中释放出来的
...
atomicity.o eh_call.o istream-inst.o pool_allocator.o
basic_file.o eh_catch.o istream.o pure.o
bitmap_allocator.o eh_exception.o libstdc++.a sstream-inst.o
c++locale.o eh_globals.o limits.o stdexcept.o
codecvt_members.o eh_personality.o list.o streambuf-inst.o
...
ctype.o functexcept.o misc-inst.o tree.o
debug_list.o globals_io.o monetary_members.o valarray-inst.o
debug.o globals_locale.o mt_allocator.o vec.o
del_opnt.o guard.o new_handler.o vterminate.o
...
eh_arm.o ios.o numeric_members.o
我们甚至可以直接使用从libstdc++.a中释放出来的tree.o，在生成可执行文件时，直接连接之。不像./libstdc++-v3/include/bits/list.tcc和vector.tcc中的函数，他们不仅是list类和vector类的成员函数，也是模板函数。因此在std_list.h文件的第73行，需要包含list.tcc文件，如上list文件(Linux平台上安装std_list.h后的文件)的内容所示。同样的道理也适用于std_vector.h文件。
我们也可以使用nm命令直接查看tree.o的相关信息。
# nm -A tree.o
tree.o:00000000 T _ZSt18_Rb_tree_decrementPKSt18_Rb_tree_node_base
tree.o:00000000 T _ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base
tree.o:00000000 T _ZSt18_Rb_tree_incrementPKSt18_Rb_tree_node_base
tree.o:00000000 T _ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base
tree.o:00000000 T _ZSt20_Rb_tree_black_countPKSt18_Rb_tree_node_baseS1_
tree.o:00000000 T _ZSt20_Rb_tree_rotate_leftPSt18_Rb_tree_node_baseRS0_
tree.o:00000000 T _ZSt21_Rb_tree_rotate_rightPSt18_Rb_tree_node_baseRS0_
tree.o:00000000 T _ZSt28_Rb_tree_rebalance_for_erasePSt18_Rb_tree_node_baseRS_
tree.o:00000000 T _ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_
tree.o: U __gxx_personality_v0
以上符号经demangle后分别与以下命令的结果相对应。
# nm -C tree.o
00000000 T std::_Rb_tree_decrement(std::_Rb_tree_node_base const*)
00000000 T std::_Rb_tree_decrement(std::_Rb_tree_node_base*)
00000000 T std::_Rb_tree_increment(std::_Rb_tree_node_base const*)
00000000 T std::_Rb_tree_increment(std::_Rb_tree_node_base*)
00000000 T std::_Rb_tree_black_count(std::_Rb_tree_node_base const*, std::_Rb_tree_node_base const*)
00000000 T std::_Rb_tree_rotate_left(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*&)
00000000 T std::_Rb_tree_rotate_right(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*&)
00000000 T std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*, std::_Rb_tree_node_base&)
00000000 T std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&)
U __gxx_personality_v0
也可以试试以下命令。对nm命令输出的解释可参考nm的manual页。
# nm -a tree.o
# nm -A tree.o
# nm -B tree.o
# nm -C tree.o (upper case)
# nm -g tree.o
# nm -l tree.o
# nm -n tree.o
# nm -o tree.o
# nm -p tree.o
# nm -P tree.o (upper case)
# nm -s tree.o
# nm -S tree.o (upper case)
# nm -u tree.o
其余均小写。
(4) 如何单步调试关于红黑树的操作，例如左旋、右旋、平衡等(tree.cc中的函数)？
回答该问题，需要调试STL的源代码。摘录如下。
(gdb) step
std::_Rb_tree, std::less, std::allocator >::_M_insert (this=0xbf849884, __x=0x0,
__p=0xbf849888, __v=@0xbf84989c)
at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:817
817 _S_key(__p)));
(gdb) n
819 _Link_type __z = _M_create_node(__v);
(gdb)
821 _Rb_tree_insert_and_rebalance(__insert_left, __z, __p,
(4.1) 利用disassemble命令找到_Rb_tree_insert_and_rebalance的符号。
(gdb) disassemble
Dump of assembler code for function _ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEE9_M_insertEPSt18_Rb_tree_node_baseS7_RKi:
...
0x08049245 <_ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEE9_M_insertEPSt18_Rb_tree_node_baseS7_RKi+149>: mov %ecx,(%esp)
0x08049248 <_ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEE9_M_insertEPSt18_Rb_tree_node_baseS7_RKi+152>: call 0x80487b8 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_@plt>
...
End of assembler dump.
可以利用c++filt命令验证该符号。
# c++filt _ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_
std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&)
(4.2) 利用disassemble命令查看该函数的起始地址
(gdb) disassemble _ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_
Dump of assembler code for function _ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_:
0x00c08750 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_+0>: push %ebp
0x00c08751 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_+1>: mov %esp,%ebp
0x00c08753 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_+3>: push %edi
0x00c08754 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_+4>: push %esi
0x00c08755 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_+5>: push %ebx
...
由上可以看出，该函数的起始地址为0x00c08750，很明显，只是一个虚拟地址，而非物理地址。
为什么要这么做？——因为函数被编译时均被mangled，成为symbol。
从如下命令可以看到在目标可执行文件中已经不存在_Rb_tree_insert_and_rebalance这样的符号了。
(gdb) disassemble _Rb_tree_insert_and_rebalance
No symbol "_Rb_tree_insert_and_rebalance" in current context.
(gdb) disassemble std::_Rb_tree_insert_and_rebalance
No symbol "_Rb_tree_insert_and_rebalance" in namespace "std".
(4.3) 在该函数中设置断点
(gdb) b *0x00c08750
Breakpoint 2 at 0xc08750
(gdb) c
Continuing.
Breakpoint 2, 0x00c08750 in std::_Rb_tree_insert_and_rebalance () from /usr/lib/libstdc++.so.6
(gdb) stepi
0x00c08751 in std::_Rb_tree_insert_and_rebalance () from /usr/lib/libstdc++.so.6
(gdb)
0x00c08753 in std::_Rb_tree_insert_and_rebalance () from /usr/lib/libstdc++.so.6
(gdb)
0x00c08754 in std::_Rb_tree_insert_and_rebalance () from /usr/lib/libstdc++.so.6
(gdb)
0x00c08755 in std::_Rb_tree_insert_and_rebalance () from /usr/lib/libstdc++.so.6
(gdb)
0x00c08756 in std::_Rb_tree_insert_and_rebalance () from /usr/lib/libstdc++.so.6
(gdb)
由此，使用stepi命令便可调试汇编代码了。
从以上调试信息可以看出，在运行过程中，_Rb_tree_insert_and_rebalance函数是从/usr/lib/libstdc++.so.6这个动态库中加载的。可以通过以下方式验证该函数在libstdc++.so.6中的位置。
# gdb /usr/lib/libstdc++.so.6.0.8
...
(gdb) disassemble _ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_
Dump of assembler code for function _ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_:
0x00c08750 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_+0>: push %ebp
0x00c08751 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_+1>: mov %esp,%ebp
0x00c08753 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_+3>: push %edi
...
题外话。
还可以通过如下方式查看该函数的汇编代码，可以看到，在tree.o中只是一个相对地址，没有虚拟地址。
# gdb ./tree.o
...
(gdb) disassemble 0
Dump of assembler code for function _ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base:
0x00000000 <_ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base+0>: push %ebp
0x00000001 <_ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base+1>: mov %esp,%ebp
0x00000003 <_ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base+3>: mov 0x8(%ebp),%ecx
0x00000006 <_ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base+6>: mov 0xc(%ecx),%edx
0x00000009 <_ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base+9>: test %edx,%edx
...
# objdump -d tree.o
...
Disassembly of section .text._ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_:
00000000 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 57 push %edi
4: 56 push %esi
5: 53 push %ebx
6: 83 ec 0c sub $0xc,%esp
9: 8b 45 14 mov 0x14(%ebp),%eax
c: 8b 7d 0c mov 0xc(%ebp),%edi
f: 8b 5d 10 mov 0x10(%ebp),%ebx
...
也可以试试以下命令。对objdump命令输出的解释可参考其的manual页。
# objdump -x tree.o
# objdump -d tree.o
# objdump -h tree.o
# objdump -s tree.o
# objdump -S tree.o (upper case)
以下问题，将另文讨论。
静态库和动态库的区别与使用
动态库如何加载？加载时虚拟地址空间如何重定位？
3. 小结
(1) 本文使用的命令
nm
objdump
c++filt
(2) STL源代码位置
GCC源代码中STL位置：./libstdc++-v3/include/bits (.表示gcc源代码目录，本文为E:/opensource/gcc-4.1.2)
Linux系统中STL位置：/usr/include/c++/4.1.2/bits
Reference
./libstdc++-v3/readme
man nm (nm的manual页)
nm -h (nm help)
Appendix: About DDD
GNU DDD is a graphical front-end for command-line debuggers such as GDB, DBX, WDB, Ladebug, JDB, XDB, the Perl debugger, the bash debugger bashdb, the GNU Make debugger remake, or the Python debugger pydb. Besides ``usual'' front-end features such as viewing source texts, DDD has become famous through its interactive graphical data display, where data structures are displayed as graphs.
是Linux平台上的一种可视化调试工具，其最大的特点是数据结构以图形方式显示，非常直观。
http://www.gnu.org/software/ddd