GDB multithreaded debugging

GDB supports multi-threaded debugging with two modes:
The default is All-stop mode, when debugging with GDB, one thread stops at the breakpoint and all other threads stop.
GDB also supports non-stop mode, where other threads continue to run when one thread stops.

Under All-stop mode, when the process stops under GDB, all the threads stop running, not just the current thread.
This way we can check all the states of the process, such as thread switching, without changing the tube.
Instead, no matter how you start the process, when you step through the command "step or Next", all the threads start executing.

In particular, GDB cannot use the single-step debug command to make all threads single-step. Because the execution thread is scheduling the operating system is not GDB, the current thread executes a step,
Other threads may have performed n-Steps. Additionally, when the process stops, the thread stops in the middle state and does not stop at the boundary state.

When executing next/step/continue, you may find that your process is stopped by another thread. The breakpoint/signal/exception is encountered by other threads before the current thread completes a single-step run.

Whenever GDB stops the process because of a breakpoint or signal, GDB chooses a thread that encounters a text message or signal interruption.
GDB prompts "[Switching to Thread n]" when switching threads

In some systems, GDB can be dispatched by locking the operating system thread, allowing only one thread to run.
Set scheduler-locking mode
Set the dispatch lock mode, and if it is off, all thread threads will run. If on, the recovery runs only when the front thread continues to run.
A single-step debug command prevents other threads from preemption, and the debug results are consistent with expectations. Under single-Step command debugging, other threads do not have a chance to run.
When Continue/util/finish is executed, other processes will also run, unless the other thread encounters a breakpoint or signal, otherwise the debug information will remain on the current thread.

Show scheduler-locking
Show current thread dispatch lock status

GDB multithreaded debugging