多线程调试调试的挑战

前面章节介绍调试器工作原理时，用于演示调试器工作过程的测试代码，有意弱化了多线程情景带来的挑战：

• 被调试的进程往往倾向于使用单线程程序，如一个简单的单进程单线程shell命令，或者使用C程序编写的单线程程序； ps：注意shell管道连接的多个命令实际上是多进程，cmd1 | cmd2 | cmd3 这其实创建了3个进程，它们通过stdin、stdout进行输入输出重定向串在了一起；
• 在介绍godbg attach、exec、continue、step、break、pregs、setregs等相关操作时，我们也还没有展开多线程情景下面临的问题；

调试多线程程序时，如果需要自由观察其中每个线程的执行情况，就要能够跟踪所有线程，存在如下问题需要解决：

• 挑战1：我们不想手动枚举进程中的所有已有线程，然后手动逐个attach
• 挑战2：进程中在后续执行时还会创建新线程、新进程，我们不想定期轮询方式去感知线程创建、进程创建，然后再手动attach
• 挑战3：多线程程序中的线程之间存在一些线程同步逻辑，如加解锁、信号量等等，只放行其中1个程序可能会导致相关任务无法正常执行
• 挑战4：多线程程序中的线程之间存在协作关系，如果某个线程命中断点停下了，但是其他相关线程还在执行，不利于观察进程整体执行情况

这就要求我们做到下面几点，多线程调试时才能便利：

• godbg attach <pid>，调试器跟踪进程时，希望能帮我们处理进程包含的所有其他线程的 attach 操作，包括已经创建的、将来才会创建的；
• 在此基础上，还希望执行 continue 等操作时能够放飞所有被跟踪且暂停执行的线程，让它们都获得执行机会以正常执行某些同步操作；
• 并且在任意线程执行时命中断点后，能够让所有线程都尽快停下来，尽管它们某些并没有命中断点，以方便调试人员观察此时的执行状态。

接下来我们用几个小节的篇幅，介绍下如何实现上述基础的多线程调试跟踪能力。