How does gdb multi-thread debugging coordinate with Linux thread scheduling?

Question

When debugging multi-thread program using gdb one can do

1. switching between existing thread
2. step debugging 
3. etc.

Meanwhile, process and its threads as resource of OS is managed by and under control of Linux Kernel. When gdb switch to a thread (say t1) from another(t2), how does it coordinate with the kernel since the kernel might still want to run t2 for some period of time. Also when gdb step is debugging in one specific thread (by issuing "si" command), how does other threads get run (or totally paused) during this period?

Answer 1

When gdb switch to a thread (say t1) from another(t2), how does it coordinate with the kernel since the kernel might still want to run t2 for some period of time.

By default, GDB operates in all-stop mode. That means that all threads are stopped whenever you see the (gdb) prompt. Switching between 2 stopped threads doesn't need any coordination with the kernel, because kernel will not run non-runnable (stopped) threads.

In a non-stop mode, threads other than current run freely, and the kernel can and will schedule them to run as it sees fit.

when gdb step is debugging in one specific thread (by issuing "si" command), how does other threads get run (or totally paused) during this period?

When you step or stepi, by default all threads are resumed. You can control this with set scheduler-locking on, in which case only the single thread will be resumed. If you forget to turn scheduler-locking off and do continue, only the current thread will be resumed, which is likely to confuse you.

Documentation.