今天在公司里练习了如何用gdb来调试code,感觉还是挺复杂的,特别是code的问题出在so里
虽然上周通过肉眼发现了问题到底在哪里,但是这毕竟是最傻的方法,作为c++ coder,我们要用native的工具来辅助自己完成debug工作
等到下次,我就会真正地用gdb来做调试了^_^
precondition:
所有的包都是-g编译出来的
要调试的问题在so库里
已经大概知道问题出在某个函数里
运行UnitTest那个二进制文件,他会卡在选择testcase的界面上
ps -u 记下pid
在.bashrc里添加so文件的路径到环境变量
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/xxx/lib
打开gdb并attach
gdb --tui
attach <pid>
用工具来demangling c++代码中的函数名字
objdump -tT function_name
nm -D function_name
如:
objdump -tT xxx.so | grep -i definelicense
0000000000063fe8 T _ZN20FSCLicenseManagement14defineLicensesEPKc
在gdb界面中输入以下内容来打断点:
break _ZN20FSCLicenseManagement14defineLicensesEPKc
此时,输入c,继续运行程序直到打断点的地方
这个时候如果运气好,那么界面上会显示断点处的源代码,否则会出现:
Current language: auto; currently asm
这个时候只能自己手动了
在gdb界面中输入:
list xxx.cpp:linenumber
此时会显示出这个文件linenumber行的代码,这时,只能一个个打断点,记录断点号,然后一次一次地continue,当到达某个断点x时core dump了,那么说明问题出现在断点x-1到x之间
注:
基本gdb命令
break 加断点
continue run直到断点
break function_name 在函数调用处加断点
step 单步
next 下一条语句
stepi 粒度更细的单步
info 显示所有信息,比如断点,寄存器等
until line_number run直到某行
虽然上周通过肉眼发现了问题到底在哪里,但是这毕竟是最傻的方法,作为c++ coder,我们要用native的工具来辅助自己完成debug工作
等到下次,我就会真正地用gdb来做调试了^_^
precondition:
所有的包都是-g编译出来的
要调试的问题在so库里
已经大概知道问题出在某个函数里
运行UnitTest那个二进制文件,他会卡在选择testcase的界面上
ps -u 记下pid
在.bashrc里添加so文件的路径到环境变量
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/xxx/lib
打开gdb并attach
gdb --tui
attach <pid>
用工具来demangling c++代码中的函数名字
objdump -tT function_name
nm -D function_name
如:
objdump -tT xxx.so | grep -i definelicense
0000000000063fe8 T _ZN20FSCLicenseManagement14defineLicensesEPKc
在gdb界面中输入以下内容来打断点:
break _ZN20FSCLicenseManagement14defineLicensesEPKc
此时,输入c,继续运行程序直到打断点的地方
这个时候如果运气好,那么界面上会显示断点处的源代码,否则会出现:
Current language: auto; currently asm
这个时候只能自己手动了
在gdb界面中输入:
list xxx.cpp:linenumber
此时会显示出这个文件linenumber行的代码,这时,只能一个个打断点,记录断点号,然后一次一次地continue,当到达某个断点x时core dump了,那么说明问题出现在断点x-1到x之间
注:
基本gdb命令
break 加断点
continue run直到断点
break function_name 在函数调用处加断点
step 单步
next 下一条语句
stepi 粒度更细的单步
info 显示所有信息,比如断点,寄存器等
until line_number run直到某行