1、GDB 多线程调试 一直对 GDB 多线程调试接触不多，最近因为工作有了一些接触，简单作点记录吧。 先介绍一下 GDB 多线程调试的基本命令。 info threads 显示当前可调试的所有线程，每个线程会有一个 GDB 为其分配的 ID，后面操作线程的时候会用到这个 ID。 前面有*的是当前调试的线程。 thread ID 切换当前调试的线程为指定 ID 的线程。 break thread_test.c:123 thread all在所有线程中相应的行上设置断点thread apply ID1 ID2 command 让一个或者多个线程执行 GDB 命令 command。 thread ap
2、ply all command 让所有被调试线程执行 GDB 命令 command。 set scheduler-locking off|on|step 估计是实际使用过多线程调试的人都可以发现，在使用 step 或者 continue 命令调试当前被调试线程的时候，其他线程也是同时执行的，怎么只让被调试程序执行呢？通过这个命令就可以实现这个需求。off 不锁定任何线程，也就是所有线程都执行，这是默认值。 on 只有当前被调试程序会执行。 step 在单步的时候，除了 next 过一个函数的情况(熟悉情况的人可能知道，这其实是一个设置断点然后 continue 的行为)以外，只有当前线程会执行
3、。 在介绍完基本的多线程调试命令后，大概介绍一下 GDB 多线程调试的实现思路。 比较主要的代码是 thread.c，前面介绍的几个命令等都是在其中实现。 thread_list 这个表存储了当前可调试的所有线程的信息。 函数 add_thread_silent 或者 add_thread(不同版本 GDB 不同)用来向 thread_list 列表增加一个线程的信息。 函数 delete_thread 用来向 thread_list 列表删除一个线程的信息。 上面提到的这 2 个函数会被有线程支持的 target 调用，用来增加和删除线程，不同的 OS对线程的实现差异很大，这么实现比较好的保
4、证了 GDB 多线程调试支持的扩展性。 函数 info_threads_command 是被命令 info threads 调用的，就是显示 thread_list 列表的信息。 函数 thread_command 是被命令 thread 调用，切换当前线程最终调用的函数是switch_to_thread，这个函数会先将当前调试线程变量 inferior_ptid，然后对寄存器和frame 缓冲进行刷新。 函数 thread_apply_command 被命令 thread apply 调用，这个函数的实际实现其实很简单，就是先切换当前线为指定线程，然后调用函数 execute_command
5、 调用指定函数。 比较特别的是 set scheduler-locking 没有实现在 thread.c 中，而是实现在控制被调试程序执行的文件 infrun.c 中。 对其的设置会保存到变量 scheduler_mode 中，而实际使用这个变量的函数只有用来令被调试程序执行的函数 resume。在默认情况下， 传递给 target_resume 的变量是resume_ptid，默认情况下其的值为 RESUME_ALL，也就是告诉 target 程序执行的时候所有 被调试线程都要被执行。而当 scheduler_mode 设置为只让当前线程执行的时候，resume_ptid 将被设置为 inf
6、erior_ptid， 这就告诉 target 只有 inferior_ptid 的线程会被执行。 最后特别介绍一下 Linux 下多线程的支持，基本的调试功能在 linux-nat.c 中，这里有对Linux 轻量级别进程本地调试的支持。但是其 在调试多线程程序的时候，还需要对 pthread调试的支持，这个功能实现在 linux-thread-db.c 中。对 pthread 的调试要通过调用 libthread_db 库来支持。 这里有一个单独的 target“multi-thread“，这个 target 有 2 点很特别: 第一，一般 target 的装载是在调用相关 to_open
7、 函数的时候调用 push_target 进行装载。而这个 target 则不同，在其初始化 的时候，就注册了函数 thread_db_new_objfile 到库文件 attach 事件中。这样当 GDB 为调试程序的动态加载库时候 attach 库文 件的时候，就会调用这个函数 thread_db_new_objfile。这样当 GDB 装载 libpthread 库的时候，最终会装载 target“multi-thread“。 第二，这个 target 并没有像大部分 target 那样自己实现了全部调试功能，其配合 linux-nat.c 的代码的功能，这里有一个 target 多层结
8、构的设计，要介绍的比较多，就不详细介绍了。 最后介绍一下我最近遇见的一个多线程调试和解决。 基本问题是在一个 Linux 环境中，调试多线程程序不正常，info threads 看不到多线程的信息。 我先用命令 maintenance print target-stack 看了一下 target 的装载情况，发现target“multi-thread“没有被装载，用 GDB 对 GDB 进行调试，发现在 函数check_for_thread_db 在调用 libthread_db 中的函数 td_ta_new 的时候，返回了TD_NOLIBTHREAD，所 以没有装载 target“multi
9、-thread“。 在时候我就怀疑是不是 libpthread 有问题，于是检查了一下发现了问题，这个环境中的libpthread 是被 strip 过的，我想可能 就是以为这个影响了 td_ta_new 对 libpthread 符号信息的获取。当我换了一个没有 strip 过的 libpthread 的时候，问题果然解决 了。 最终我的解决办法是拷贝了一个.debug 版本的 libpthread 到 lib 目录中，问题解决了。 多线程如果 dump，多为段错误，一般都涉及内存非法读写。可以这样处理，使用下面的命令打开系统开关，让其可以在死掉的时候生成 core 文件。 ulimit -
10、c unlimited这样的话死掉的时候就可以在当前目录看到 core.pid(pid 为进程号)的文件。接着使用 gdb:gdb ./bin ./core.pid 进去后，使用 bt 查看死掉时栈的情况，在使用 frame 命令。还有就是里面某个线程停住，也没死，这种情况一般就是死锁或者涉及消息接受的超时问题(听人说的，没有遇到过)。遇到这种情况，可以使用：gcore pid （调试进程的 pid 号）手动生成 core 文件，在使用 pstack(linux 下好像不好使)查看堆栈的情况。如果都看不出来，就仔细查看代码，看看是不是在 if，return，break，continue 这种语句操作是忘记解锁，还有嵌套锁的问题，都需要分析清楚了。
