使用GDB调试RB-tree的几个问题
2011-04-02 22:39
417 查看
本博客http://blog.csdn.net/livelylittlefish 贴出作者（三二一@小鱼）相关研究、学习内容所做的笔记，欢迎广大朋友指正！
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# lscrtbegin.o finclude libgcj.so libgfortran.so libstdc++.socrtbeginS.o include libgcj.spec libgij.so libsupc++.acrtbeginT.o libgcc.a libgcj-tools.so libgomp.a SYSCALLS.c.Xcrtend.o libgcc_eh.a libgcov.a libgomp.socrtendS.o libgcc_s.so libgfortran.a libgomp.speccrtfastmath.o libgcj_bc.so libgfortranbegin.a libstdc++.a # objdump -x libsupc++.a | grep newnew_handler.o: file format elf32-i386rw-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**200000000 l d .text._ZSt15set_new_handlerPFvvE 00000000 .text._ZSt15set_new_handlerPFvvE00000000 l d .bss.__new_handler 00000000 .bss.__new_handler00000000 g F .text._ZSt15set_new_handlerPFvvE 0000001f _ZSt15set_new_handlerPFvvE00000000 g O .bss.__new_handler 00000004 __new_handlerRELOCATION RECORDS FOR [.text._ZSt15set_new_handlerPFvvE]:00000014 R_386_GOT32 __new_handler00000024 R_386_PC32 .text._ZSt15set_new_handlerPFvvEnew_op.o: file format elf32-i386rw-r--r-- 102/102 2432 Oct 21 23:42 2007 new_op.o00000000 *UND* 00000000 __new_handler0000002d R_386_GOT32 __new_handlernew_opnt.o: file format elf32-i386rw-r--r-- 102/102 2360 Oct 21 23:42 2007 new_opnt.o00000000 *UND* 00000000 __new_handler00000030 R_386_GOT32 __new_handlernew_opv.o: file format elf32-i386rw-r--r-- 102/102 2100 Oct 21 23:42 2007 new_opv.onew_opvnt.o: file format elf32-i386rw-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**400000000 l d .text.__cxa_vec_new2 00000000 .text.__cxa_vec_new200000000 l d .text.__cxa_vec_new 00000000 .text.__cxa_vec_new00000000 l d .text.__cxa_vec_new3 00000000 .text.__cxa_vec_new300000000 g F .text.__cxa_vec_new2 000000c5 __cxa_vec_new200000000 g F .text.__cxa_vec_new 00000053 __cxa_vec_new00000000 g F .text.__cxa_vec_new3 000000cc __cxa_vec_new3RELOCATION RECORDS FOR [.text.__cxa_vec_new2]:RELOCATION RECORDS FOR [.text.__cxa_vec_new]:00000049 R_386_PLT32 __cxa_vec_new2RELOCATION RECORDS FOR [.text.__cxa_vec_new3]:0000014c R_386_PC32 .text.__cxa_vec_new200000174 R_386_PC32 .text.__cxa_vec_new00000194 R_386_PC32 .text.__cxa_vec_new3 # nm libsupc++.a | grep newnm: eh_arm.o: no symbolsnew_handler.o:00000000 T _ZSt15set_new_handlerPFvvE00000000 B __new_handlernew_op.o: U __new_handlernew_opnt.o: U __new_handlernew_opv.o:new_opvnt.o:00000000 T __cxa_vec_new00000000 T __cxa_vec_new200000000 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_handlerstd::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) stepstd::_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:817817 _S_key(__p)));(gdb) n819 _Link_type __z = _M_create_node(__v);(gdb) 821 _Rb_tree_insert_and_rebalance(__insert_left, __z, __p, (gdb) step823 ++_M_impl._M_node_count;(gdb) l818819 _Link_type __z = _M_create_node(__v);820821 _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# lsalgorithm clocale ctime functional java ostream typeinfobackward cmath cwchar gcj javax queue utilitybits complex cwctype gnu limits set valarraybitset 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是动态库，其中没有symbolsnm: libstdc++.so: no symbols # nm libstdc++.a | grep _Rb_tree_00000000 T _ZSt18_Rb_tree_decrementPKSt18_Rb_tree_node_base00000000 T _ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base00000000 T _ZSt18_Rb_tree_incrementPKSt18_Rb_tree_node_base00000000 T _ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base00000000 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 symbolsnm: eh_arm.o: no symbols # c++filt _ZSt18_Rb_tree_decrementPKSt18_Rb_tree_node_basestd::_Rb_tree_decrement(std::_Rb_tree_node_base const*) # c++filt _ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_basestd::_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# lslibstdc++.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.obasic_file.o eh_catch.o istream.o pure.obitmap_allocator.o eh_exception.o libstdc++.a sstream-inst.oc++locale.o eh_globals.o limits.o stdexcept.ocodecvt_members.o eh_personality.o list.o streambuf-inst.o...ctype.o functexcept.o misc-inst.o tree.odebug_list.o globals_io.o monetary_members.o valarray-inst.odebug.o globals_locale.o mt_allocator.o vec.odel_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) stepstd::_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:817817 _S_key(__p)));(gdb) n819 _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 %ebp0x00c08751 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_+1>: mov %esp,%ebp0x00c08753 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_+3>: push %edi0x00c08754 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_+4>: push %esi0x00c08755 <_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_rebalanceNo symbol "_Rb_tree_insert_and_rebalance" in current context.(gdb) disassemble std::_Rb_tree_insert_and_rebalanceNo symbol "_Rb_tree_insert_and_rebalance" in namespace "std". (4.3) 在该函数中设置断点 (gdb) b *0x00c08750Breakpoint 2 at 0xc08750(gdb) cContinuing. Breakpoint 2, 0x00c08750 in std::_Rb_tree_insert_and_rebalance () from /usr/lib/libstdc++.so.6(gdb) stepi0x00c08751 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 %ebp0x00c08751 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_+1>: mov %esp,%ebp0x00c08753 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_+3>: push %edi... 题外话。 还可以通过如下方式查看该函数的汇编代码，可以看到，在tree.o中只是一个相对地址，没有虚拟地址。 # gdb ./tree.o...(gdb) disassemble 0Dump of assembler code for function _ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base:0x00000000 <_ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base+0>: push %ebp0x00000001 <_ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base+1>: mov %esp,%ebp0x00000003 <_ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base+3>: mov 0x8(%ebp),%ecx0x00000006 <_ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base+6>: mov 0xc(%ecx),%edx0x00000009 <_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
Technorati 标签: STL, RB-tree, 红黑树, GDB
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# lscrtbegin.o finclude libgcj.so libgfortran.so libstdc++.socrtbeginS.o include libgcj.spec libgij.so libsupc++.acrtbeginT.o libgcc.a libgcj-tools.so libgomp.a SYSCALLS.c.Xcrtend.o libgcc_eh.a libgcov.a libgomp.socrtendS.o libgcc_s.so libgfortran.a libgomp.speccrtfastmath.o libgcj_bc.so libgfortranbegin.a libstdc++.a # objdump -x libsupc++.a | grep newnew_handler.o: file format elf32-i386rw-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**200000000 l d .text._ZSt15set_new_handlerPFvvE 00000000 .text._ZSt15set_new_handlerPFvvE00000000 l d .bss.__new_handler 00000000 .bss.__new_handler00000000 g F .text._ZSt15set_new_handlerPFvvE 0000001f _ZSt15set_new_handlerPFvvE00000000 g O .bss.__new_handler 00000004 __new_handlerRELOCATION RECORDS FOR [.text._ZSt15set_new_handlerPFvvE]:00000014 R_386_GOT32 __new_handler00000024 R_386_PC32 .text._ZSt15set_new_handlerPFvvEnew_op.o: file format elf32-i386rw-r--r-- 102/102 2432 Oct 21 23:42 2007 new_op.o00000000 *UND* 00000000 __new_handler0000002d R_386_GOT32 __new_handlernew_opnt.o: file format elf32-i386rw-r--r-- 102/102 2360 Oct 21 23:42 2007 new_opnt.o00000000 *UND* 00000000 __new_handler00000030 R_386_GOT32 __new_handlernew_opv.o: file format elf32-i386rw-r--r-- 102/102 2100 Oct 21 23:42 2007 new_opv.onew_opvnt.o: file format elf32-i386rw-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**400000000 l d .text.__cxa_vec_new2 00000000 .text.__cxa_vec_new200000000 l d .text.__cxa_vec_new 00000000 .text.__cxa_vec_new00000000 l d .text.__cxa_vec_new3 00000000 .text.__cxa_vec_new300000000 g F .text.__cxa_vec_new2 000000c5 __cxa_vec_new200000000 g F .text.__cxa_vec_new 00000053 __cxa_vec_new00000000 g F .text.__cxa_vec_new3 000000cc __cxa_vec_new3RELOCATION RECORDS FOR [.text.__cxa_vec_new2]:RELOCATION RECORDS FOR [.text.__cxa_vec_new]:00000049 R_386_PLT32 __cxa_vec_new2RELOCATION RECORDS FOR [.text.__cxa_vec_new3]:0000014c R_386_PC32 .text.__cxa_vec_new200000174 R_386_PC32 .text.__cxa_vec_new00000194 R_386_PC32 .text.__cxa_vec_new3 # nm libsupc++.a | grep newnm: eh_arm.o: no symbolsnew_handler.o:00000000 T _ZSt15set_new_handlerPFvvE00000000 B __new_handlernew_op.o: U __new_handlernew_opnt.o: U __new_handlernew_opv.o:new_opvnt.o:00000000 T __cxa_vec_new00000000 T __cxa_vec_new200000000 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_handlerstd::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) stepstd::_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:817817 _S_key(__p)));(gdb) n819 _Link_type __z = _M_create_node(__v);(gdb) 821 _Rb_tree_insert_and_rebalance(__insert_left, __z, __p, (gdb) step823 ++_M_impl._M_node_count;(gdb) l818819 _Link_type __z = _M_create_node(__v);820821 _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# lsalgorithm clocale ctime functional java ostream typeinfobackward cmath cwchar gcj javax queue utilitybits complex cwctype gnu limits set valarraybitset 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是动态库，其中没有symbolsnm: libstdc++.so: no symbols # nm libstdc++.a | grep _Rb_tree_00000000 T _ZSt18_Rb_tree_decrementPKSt18_Rb_tree_node_base00000000 T _ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base00000000 T _ZSt18_Rb_tree_incrementPKSt18_Rb_tree_node_base00000000 T _ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base00000000 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 symbolsnm: eh_arm.o: no symbols # c++filt _ZSt18_Rb_tree_decrementPKSt18_Rb_tree_node_basestd::_Rb_tree_decrement(std::_Rb_tree_node_base const*) # c++filt _ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_basestd::_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# lslibstdc++.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.obasic_file.o eh_catch.o istream.o pure.obitmap_allocator.o eh_exception.o libstdc++.a sstream-inst.oc++locale.o eh_globals.o limits.o stdexcept.ocodecvt_members.o eh_personality.o list.o streambuf-inst.o...ctype.o functexcept.o misc-inst.o tree.odebug_list.o globals_io.o monetary_members.o valarray-inst.odebug.o globals_locale.o mt_allocator.o vec.odel_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) stepstd::_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:817817 _S_key(__p)));(gdb) n819 _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 %ebp0x00c08751 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_+1>: mov %esp,%ebp0x00c08753 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_+3>: push %edi0x00c08754 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_+4>: push %esi0x00c08755 <_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_rebalanceNo symbol "_Rb_tree_insert_and_rebalance" in current context.(gdb) disassemble std::_Rb_tree_insert_and_rebalanceNo symbol "_Rb_tree_insert_and_rebalance" in namespace "std". (4.3) 在该函数中设置断点 (gdb) b *0x00c08750Breakpoint 2 at 0xc08750(gdb) cContinuing. Breakpoint 2, 0x00c08750 in std::_Rb_tree_insert_and_rebalance () from /usr/lib/libstdc++.so.6(gdb) stepi0x00c08751 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 %ebp0x00c08751 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_+1>: mov %esp,%ebp0x00c08753 <_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_+3>: push %edi... 题外话。 还可以通过如下方式查看该函数的汇编代码，可以看到，在tree.o中只是一个相对地址，没有虚拟地址。 # gdb ./tree.o...(gdb) disassemble 0Dump of assembler code for function _ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base:0x00000000 <_ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base+0>: push %ebp0x00000001 <_ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base+1>: mov %esp,%ebp0x00000003 <_ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base+3>: mov 0x8(%ebp),%ecx0x00000006 <_ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base+6>: mov 0xc(%ecx),%edx0x00000009 <_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
Technorati 标签: STL, RB-tree, 红黑树, GDB
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 使用GDB调试RB-tree的几个问题(更正)
- 使用GDB调试RB-tree的几个问题
- 使用GDB调试RB-tree
- Eclipse - CDT使用GDB调试C++的问题-无源文件命名(No source file named)
- 使用gdb对core dump问题进行调试
- 使用sem_t导致不能用gdb调试及线程非正常终止后message queue异常的问题
- 使用gdb调试网络程序时，收到SIGPIPE信号异常退出问题
- 直接使用JDB解决ndk-gdb调试时的“waiting for debugger”弹窗不消失问题
- Eclipse - CDT使用GDB调试C++的问题-无源文件命名(No source file named)
- Eclipse - CDT使用GDB调试C++的问题-无源文件命名(No source file named)
- 解决TcxTreeList使用的几个问题
- 关于VS 使用GDB工具调试ADT下JNI时遇到的一些问题的解决
- 多线程之问题的解决及使用GDB调试多线程多进程的手段(九)
- Centos7 使用GDB调试时的问题：Missing separate debuginfos, use: debuginfo-install libgccxxx
- 使用GDB调试PHP代码，解决PHP代码死循环问题
- 使用GDB调试PHP代码，解决PHP代码死循环问题
- gdb调试时No symbol "var" defined in current context，局部变量不可查看问题
- 使用GDB调试Android NDK native(C/C++)程序
- 计划在以后的项目中使用Enterprise Library，就几个问题咨询各位
- Web开发基础--WebService调试过程中遇到的几个问题