线程执行控制 - continue

实现目标：多线程环境下的continue命令

前面我们已经介绍了如何跟踪进程中的已有线程（21-trace_old_threads.md）和后续执行期间新创建的线程（20-trace_new_threads.md），现在我们需要实现多线程环境下的continue命令。

在多线程调试中，continue命令的实现面临以下挑战：

线程同步问题：如果只恢复一个线程的执行，而其他线程仍处于暂停状态，可能导致线程间的同步操作（如互斥锁、信号量等）无法正常工作
断点处理复杂性：当某个线程命中断点停止时，需要正确处理断点恢复、PC调整等操作，同时确保其他线程也能正常继续执行
线程状态管理：需要维护所有被跟踪线程的状态信息，确保在continue操作时能够统一管理所有线程的执行状态
事件通知机制：当任意线程命中断点或发生其他调试事件时，需要能够及时通知调试器并暂停所有相关线程

我们的目标是实现一个支持多线程的continue命令，能够：

统一管理所有被跟踪线程的执行状态
正确处理断点恢复和PC调整
确保线程间的同步操作能够正常工作
在任意线程命中断点时能够暂停所有线程，方便调试人员观察

基础知识

Stop-All Mode vs Stop-One Mode

在多线程调试中，有两种主要的线程管理模式：

Stop-All Mode（全停模式）：

当任意线程命中断点或发生调试事件时，所有线程都会停止执行
这种模式便于调试人员观察进程的整体状态，避免线程间的不一致
大多数现代调试器（如GDB、LLDB）默认采用这种模式

Stop-One Mode（单停模式）：

只有命中断点的线程停止，其他线程继续执行
这种模式可能导致线程间同步问题，但有时对性能敏感的应用有用
需要调试人员对多线程程序有深入理解

对于Go程序调试，我们推荐使用Stop-All Mode，因为Go的GMP调度模型使得线程间的协作关系更加复杂。

线程状态管理

在多线程调试中，每个被跟踪的线程都有以下状态：

type ThreadState int

const (
    ThreadStateRunning ThreadState = iota  // 线程正在执行
    ThreadStateStopped                     // 线程已停止
    ThreadStateStoppedAtBreakpoint         // 线程停在断点处
    ThreadStateStoppedAtSignal             // 线程因信号停止
    ThreadStateDetached                    // 线程已脱离跟踪
)

断点恢复机制

当线程命中断点停止时，需要执行以下操作：

检查断点：确认当前PC-1位置是否为断点指令（0xCC）
恢复指令：将断点位置的0xCC替换为原始指令
调整PC：将PC寄存器回退1，指向原始指令地址
单步执行：执行单步操作，让线程执行原始指令
重新设置断点：在原始位置重新设置断点，以便后续触发

设计实现

多线程Continue命令的伪代码实现

func (dbp *DebuggerProcess) Continue() error {
    // 1. 获取所有被跟踪的线程
    threads := dbp.GetAllTrackedThreads()

    // 2. 检查是否有线程停在断点处
    bpStoppedThreads := make(map[int]uintptr)
    for _, thread := range threads {
        if thread.State == ThreadStateStoppedAtBreakpoint {
            bpAddr := thread.GetCurrentPC() - 1
            bpStoppedThreads[thread.ID] = bpAddr
        }
    }

    // 3. 处理停在断点处的线程
    if len(bpStoppedThreads) > 0 {
        // 3.1 恢复断点指令
        for threadID, bpAddr := range bpStoppedThreads {
            // 恢复原始指令
            originalByte := dbp.GetBreakpointOriginalByte(bpAddr)
            dbp.WriteMemory(threadID, bpAddr, []byte{originalByte})

            // 调整PC寄存器
            regs := dbp.GetRegisters(threadID)
            regs.SetPC(bpAddr)
            dbp.SetRegisters(threadID, regs)

            // 单步执行
            dbp.SingleStep(threadID)

            // 重新设置断点
            dbp.SetBreakpoint(bpAddr)
        }
    }

    // 4. 恢复所有线程执行
    for _, thread := range threads {
        if thread.State == ThreadStateStopped {
            dbp.ContinueThread(thread.ID)
        }
    }

    // 5. 等待任意线程停止
    return dbp.WaitForThreadStop()
}

线程停止事件处理

func (dbp *DebuggerProcess) WaitForThreadStop() error {
    for {
        // 等待任意线程状态变化
        stoppedThreadID, status, err := dbp.WaitForAnyThread()
        if err != nil {
            return err
        }

        // 检查停止原因
        if status.IsBreakpoint() {
            // 线程命中断点，停止所有其他线程
            dbp.StopAllThreads()
            return nil
        } else if status.IsSignal() {
            // 线程因信号停止，根据信号类型决定是否停止所有线程
            if dbp.ShouldStopAllForSignal(status.Signal()) {
                dbp.StopAllThreads()
                return nil
            }
        }

        // 继续等待其他线程停止
    }
}

线程同步控制

func (dbp *DebuggerProcess) StopAllThreads() error {
    threads := dbp.GetAllTrackedThreads()

    for _, thread := range threads {
        if thread.State == ThreadStateRunning {
            // 发送SIGSTOP信号停止线程
            err := syscall.Kill(thread.ID, syscall.SIGSTOP)
            if err != nil {
                return fmt.Errorf("failed to stop thread %d: %v", thread.ID, err)
            }
        }
    }

    // 等待所有线程停止
    for _, thread := range threads {
        if thread.State == ThreadStateRunning {
            _, err := dbp.WaitForThread(thread.ID)
            if err != nil {
                return fmt.Errorf("failed to wait for thread %d: %v", thread.ID, err)
            }
        }
    }

    return nil
}

测试程序

为了测试多线程continue功能，我们需要一个包含线程同步操作的多线程程序：

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <pthread.h>
#include <sys/syscall.h>

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
int shared_counter = 0;

void *worker_thread(void *arg) {
    int thread_id = *(int*)arg;

    for (int i = 0; i < 10; i++) {
        // 加锁
        pthread_mutex_lock(&mutex);

        // 临界区操作
        shared_counter++;
        printf("Thread %d: counter = %d\n", thread_id, shared_counter);

        // 解锁
        pthread_mutex_unlock(&mutex);

        // 模拟一些工作
        usleep(100000); // 100ms
    }

    return NULL;
}

int main() {
    printf("Main thread: PID=%d, TID=%ld\n", getpid(), syscall(SYS_gettid));

    pthread_t threads[3];
    int thread_ids[3] = {1, 2, 3};

    // 创建多个工作线程
    for (int i = 0; i < 3; i++) {
        if (pthread_create(&threads[i], NULL, worker_thread, &thread_ids[i]) != 0) {
            perror("pthread_create");
            exit(1);
        }
    }

    // 等待所有线程完成
    for (int i = 0; i < 3; i++) {
        pthread_join(threads[i], NULL);
    }

    printf("Final counter value: %d\n", shared_counter);
    return 0;
}

这个测试程序的特点：

包含多个工作线程
使用互斥锁进行线程同步
每个线程都会访问共享资源
适合测试多线程continue功能

代码测试

测试步骤：

编译测试程序：gcc -o multithread_test multithread_test.c -lpthread
运行测试程序：./multithread_test
启动调试器：godbg attach <pid>
设置断点：在临界区代码处设置断点
执行continue：验证多线程continue功能

预期结果：

当任意线程命中断点时，所有线程都应该停止
执行continue后，所有线程都应该恢复执行
线程间的同步操作应该能够正常工作
共享资源的状态应该保持一致

思考一下：Go程序的多线程调试特殊性

Go程序的多线程调试有其特殊性：

GMP调度模型：Go使用goroutine和M（machine thread）的调度模型，一个M可能执行多个goroutine
运行时调度：Go运行时会在goroutine之间进行调度，这使得线程级别的调试变得复杂
CGO代码：如果程序包含CGO代码，这些代码会在线程级别执行，需要特殊的调试支持

因此，对于Go程序的多线程调试，我们可能需要：

支持goroutine级别的调试
处理运行时调度器的特殊行为
区分用户代码和运行时代码的断点设置

思考一下：性能优化考虑

在多线程调试中，性能是一个重要考虑因素：

线程数量：现代程序可能包含数百个线程，需要高效的线程管理
事件处理：需要快速响应线程状态变化
内存使用：需要合理管理调试信息的内存占用

优化策略：

使用事件驱动的线程管理
实现线程池来管理调试线程
采用延迟加载策略减少内存占用

本节小结

本节深入探讨了多线程调试中continue命令的实现原理和设计考虑，重点阐述了三个核心技术点：通过Stop-All Mode确保所有线程的统一管理；利用断点恢复机制正确处理线程停止和恢复；采用线程同步控制避免线程间的不一致状态。此外，本节还分析了Go程序多线程调试的特殊性，以及性能优化的重要考虑因素。这些内容为读者构建了完整的多线程调试知识体系，为后续实现完整的调试器功能奠定了坚实的技术基础。

6.20.4 线程执行控制 - continue