本文目录一览：
- 1、如何用vs code调试运行c语言程序
- 2、GDB ROS调试
- 3、gdb怎么用
- 4、初步接触linux，请问gdb调试start后加载动态库符号时间很长，怎么解决，可以不加载指定库符号吗？
- 5、GDB 调试命令
- 6、如何在Docker内部使用gdb调试器
如何用vs code调试运行c语言程序
VS Code虽然是个编辑器，但也能作为gdb的前端来启动调试，实际调用的是gdb。
点击VSCode左边的“虫子”图标，然后点齿轮，就会让你配置启动调试json文件。
只要就是改一下启动程序名，改为你要调试 的文件，保存。
在程序中点击行号打上断点，然后点击“绿色的箭头”就会启动调试。
GDB ROS调试
ROS中用到第三方库，在编译第三方库的时候，加上 -g 选项，以供调用该库时调试。
在编译ROS包的时候，使用如下命令编译：
catkin_make -DCMAKE_BUILD_TYPE=Debug
GDB启动应用
rosrun --prefix 'gdb -ex run --args' package node
之后就可以正常使用GDB命令来调试了，因为第三方库编译加了 -g 选项，所以可以进入调用库中的函数进行调试。
gdb怎么用
GDB调试，建议去下个系统的文档；
GDB调试器
GCC用于编译程序，而Linux的另一个GNU工具gdb则用于调试程序。gdb是一个用来调试C和C++程序的强力调试器，我们能通过它进行一系列调试工作，包括设置断点、观查变量、单步等。
其最常用的命令如下：
file：装入想要调试的可执行文件。
kill：终止正在调试的程序。
list：列表显示源代码。
next：执行一行源代码但不进入函数内部。
step：执行一行源代码而且进入函数内部。
run：执行当前被调试的程序
quit：终止gdb
watch：监视一个变量的值
break：在代码里设置断点，程序执行到这?锸惫移?
make：不退出gdb而重新产生可执行文件
shell：不离开gdb而执行shell
2）从你的描述上看来，你是用单独的gdb.exe调试器，调试的时候不需要运行程序的，编译的时候 只要加上相应的参数（”-g“）产生编译后的可执行文件，
以gcc编译sum.c（加-g选项产生debug信息）：
gcc –g –o sum sum.c
在命令行上键入gdb sum并按回车键就可以开始调试sum了，再运行run命令执行sum。
初步接触linux，请问gdb调试start后加载动态库符号时间很长，怎么解决，可以不加载指定库符号吗？
方法一、在/etc/ld.so.conf文件中添加路径，vi /etc/ld.so.conf
添加下边内容
123
include ld.so.conf.d/*.conf /usr/cluster/.share/lib
方法二、在终端输入：export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/cluster/.share/lib
方法三、修改/etc/profile文件
123
export MPI_HOME=/usr/cluster export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$MPI_HOME/.share/lib
在终端执行source /etc/profile 使配置文件生效
程序运行时加载动态库失败的解决方法
错误提示如下：
error while loading shared libraries: libjson.so.0: cannot open shared object file: No such file or directory
原因一般有两个，一个是操作系统中没有包含该共享库(lib*.so.* 文件)或者共享库版本不对。解决办法就是重新下载安装。
另外一个原因就是已经安装了该共享库，但是执行需要调用该共享库的程序的时候，程序按照默认共享库路径找不到该共享库文件。解决方法如下：
如果共享库文件安装到了 /lib 或 /usr/lib 目录下，那么执行一下 ldconfig 命令。
ldconfig命令的用途, 主要是在默认搜寻目录(b和/usrb)以及动态库配置文件/etc/ld.so.conf内所列的目录下, 搜索出可共享的动态链接库(格式如lib*.so*), 进而创建出动态装入程序(ld.so)所需的连接和缓存文件. 缓存文件默认为/etc/ld.so.cache, 此文件保存已排好序的动态链接库名字列表.
如果共享库文件安装到了 /usr/local/lib (一般开源的共享库都会安装到该目录下)或者其它非 /lib 或 /usr/lib 目录下，那么在执行 ldconfig 命令前，还要把新的共享库目录加入到共享库配置文件 /etc/ld.so.conf 中，如下：
1234
# cat /etc/ld.so.confinclude ld.so.conf.d/*.conf# echo "/usr/local/lib" /etc/ld.so.conf# ldconfig
或者在 /etc/ld.so.conf.d/ 目录下新建任何以 .conf 为后缀的文件，在该文件中加入库文件所在的目录。然后执行 ldconfig 更新 /etc/ld.so.cache 文件。
如果共享库文件安装到了其他非 /lib 或 /usr/lib 目录下,但是又不想在 /etc/ld.so.conf 文件中加共享库路径(或者是没有权限加路径)。那可以 export 一个全局变量 LD_LIBRARY_PATH,然后运行程序的时候就会去找个目录中找共享库。
LD_LIBRARY_PATH的意思是告诉loader在哪些目录中可以找到共享库. 可以设置多个搜索目录, 这些目录之间用冒号分隔开. 比如安装了一个mysql到/usr/local/mysql目录下, 其中有一大堆库文件在/usr/local/mysql/lib下面, 则可以在.bashrc或.bash_profile或shell里加入以下语句即可:
export LD_LIBRARY_PATH=/usr/local/mysql/lib:$LD_LIBRARY_PATH
一般来讲这只是一种临时的解决方案, 在没有权限或临时需要的时候使用.
如果程序需要的库文件比系统目前存在的库文件版本低，可以做一个链接。比如：
12345
error while loading shared libraries: libncurses.so.4: cannot open sharedobject file: No such file or directoryls /usr/lib/libncu*/usr/lib/libncurses.a /usr/lib/libncurses.so.5/usr/lib/libncurses.so /usr/lib/libncurses.so.5.3
可见虽然没有libncurses.so.4，但有libncurses.so.5，是可以向下兼容的
建一个链接就好了
1
ln -s /usr/lib/libncurses.so.5.3 /usr/lib/libncurses.so.4
GDB 调试命令
(gdb) i r
(gdb) i r a # 查看所有寄存器（包括浮点、多媒体）
(gdb) i r esp
(gdb) i r pc
(gdb) x /wx 0x80040000 # 以16进制显示指定地址处的数据
(gdb) x /8x esp+12
(gdb) x /16s 0x86468700 # 以字符串形式显示指定地址处的数据
(gdb) x /24i 0x8048a51 # 以指令形式显示指定地址处的数据（24条）
(gdb) set $v0 = 0x004000000
(gdb) set $epc = 0xbfc00000
(gdb) set {unsigned int}0x8048a51=0x0
(gdb) set (unsigned int )0x8048a54=0x55aa55aa
Usage: find start end count value
(gdb) b *0x80400000
(gdb) watch *(unsigned int *)0xbffff400==0x90909090
更多
如何在Docker内部使用gdb调试器
前几天一个小伙伴发邮件问我，他在docker内部使用gdb调试时刻遇到了gdb如下报错信息
ptrace:Operation not permitted
当时我的答复是在docker create或者docker run时刻开启 万精油--privileged参数 。小伙伴的问题就此解决了。
但是事实并非如此简单
Docker借用了linux对进程设置capabilities，而其子进程继承父进程capabilites特性来完成对容器capacities的控制。Docker create和docker run参数中有下面两个参数可以对容器默认的capabilites进行修改：
--cap-add //添加某个capabilites属性 --cap-del //剔除某个默认的capabilites属性
cap-add和cap-del可以设置的参数可以通过下面链接查询到：
但是这并不是问题的全部，对于上述测试程序，如果执行下面命令gdb又有告警出来
虽然依然可以调试，但是我们还是需要搞清楚上述告警的意思。地址随机化是linux一项安全特性，它允许内核进程启动每次加载库的时候都在随机化的分布在进程虚拟内存地址空间上(早期固定的库要加载到固定地方，如果固定地方被占用才加载到别地方。会造成多次加载程序，其库地址都不变。如此有安全隐患)。在gdb调试中gdb默认需要关闭linux的地址随机化功能，可以通过gdb 命令set disable-randomization off关闭。 如果在地址随机化下调试同一段程序，多次run时候可以看到它的运行地址和函数地址不一致，这没有什么太大的问题。问题可以结束一半了
关于gdb 设置地址随机化开关详情见下面链接：
当然上述告警其实也可以不通过gdb设置来完成，可以通过下面介绍的Docker参数可以达成。
Docker默认情况下为每个容器都设置了一个默认的seccom profile。一般情况下无需修改。但是docker依然支持
docker create或者docker run时候通过--security-opt seccomp=xxx参数来设置docker容器的seccomp策略。
xxx可以是一个json格式文件，里面定义了docker容器每个具体的seccomp规则。也可以是字符unconfined表示关闭默认的docker seccomp 规则。
可以通过下面命令彻底关闭docker默认seccomp引入的任何限制
docker run -it --security-opt seccomp=unconfined centos:lastes
在运行上述gdb 调试命令run一个进程，告警信息终于彻底消失了。
Docker设置的seccomp 默认profile规则可以通过如下链接查询到：
本文就不再做详细展开了。
从Linux 2.6.23开始支持这种特性对进程能够使用的系统调用进行控制，如此可以进行一些安全性策略。sandbox就是依赖于此技术。docker梳理了Linux的系统调用，从300+个系统调用中屏蔽掉了44个系统调用，但是又最大程度的不影响正常的应用使用系统。
从Linux 2.1开始支持的特性，将超级用户的权限划分为多个组，每个进程都有一个capabilities属性，子进程从自己的父进程中基础capacities。这个特性和sudo不一样，因为sudo控制粒度太粗；而capabilities控制粒度很精细。linux有一系列的调用可以设置、查看，清除和比较进程的capabilities。可以通过：
man cap_set_flag
来查看这一系列的系统调用。而具体进程的capacities可以通过/proc/$pid/status中：
Capxxx字段看到，本文就不再展开。感兴趣的朋友可以参考