GDB多线程调试与Linux线程调度的协同机制探究

Great question—this dives into the under-the-hood mechanics of how GDB works with the Linux kernel for multi-threaded apps, which is key to avoiding confusion when debugging concurrent code. Let’s break this down into two clear parts:

1. How GDB coordinates with the kernel when switching from thread t2 to t1 #

First, remember that on Linux, threads are implemented as Light Weight Processes (LWPs)—each thread has its own PID and is managed independently by the kernel. GDB relies on the ptrace system call to interact with the kernel and control these LWPs. Here’s the play-by-play when switching threads:

• Before making the switch, GDB ensures the current thread (t2) is paused. If t2 was running (e.g., you’d just resumed it), GDB sends a SIGSTOP signal via ptrace, telling the kernel to halt t2’s execution immediately.
• GDB then looks up the LWP ID linked to thread t1 (it maintains a mapping between GDB’s internal thread IDs and the kernel’s LWP IDs).
• Using ptrace, GDB pulls t1’s full execution context—registers, stack state, memory pointers—from the kernel, and updates its own debugging session to use this context.
• The kernel tracks the debug state of every LWP (whether it’s being traced, why it’s paused). As long as GDB keeps a ptrace attachment to t2, the kernel won’t schedule t2 to run again unless GDB explicitly sends a SIGCONT signal to resume it. So even if the kernel’s scheduler would normally pick t2, it can’t run because t2 is locked in a stopped state controlled by GDB.

2. What happens to other threads when using si on a specific thread #

This depends on GDB’s active debugging mode—here are the two common scenarios:

Default: All-stop mode #

By default, GDB runs in all-stop mode. When you run si (step instruction) on a target thread:

• GDB first sends SIGSTOP to all other threads in the process, pausing them via the kernel.
• It then resumes the target thread for exactly one machine instruction, immediately sending another SIGSTOP to pause it again once the instruction finishes.
• All other threads stay paused until you explicitly resume them (e.g., with continue or thread apply all continue). This lets you focus on stepping through the target thread without concurrent execution from other threads messing with your debug flow.

Optional: Non-stop mode #

If you want other threads to keep running while stepping a specific thread, you can enable non-stop mode with this command:

set non-stop on

In this mode:

• When you run si on the target thread, only that thread is controlled by GDB. It’s paused, runs one instruction, then pauses again.
• All other threads are left to be scheduled normally by the kernel—they can run, execute their code, and make system calls without being interrupted by GDB (unless they hit a breakpoint, trigger a signal, or another debug event GDB is listening for).
• This is perfect for debugging race conditions or scenarios where you need to observe how the target thread interacts with actively running threads.

内容的提问来源于stack exchange，提问作者isamateur