Debugging with GDB: Thread-Specific Breakpoints |
---|
Next: Interrupted System Calls, Previous: Background Execution, Up: Thread Stops [Contents][Index]
When your program has multiple threads (see Debugging Programs with Multiple Threads), you can choose whether to set breakpoints on all threads, or on a particular thread.
break location thread thread-id
break location thread thread-id if …
location specifies source lines; there are several ways of writing them (see Specify Location), but the effect is always to specify some source line.
Use the qualifier ‘thread thread-id ’ with a breakpoint command to specify that you only want GDB to stop the program when a particular thread reaches this breakpoint. The thread-id specifier is one of the thread identifiers assigned by GDB, shown in the first column of the ‘info threads’ display.
If you do not specify ‘thread thread-id ’ when you set a breakpoint, the breakpoint applies to all threads of your program.
You can use the thread
qualifier on conditional breakpoints as
well; in this case, place ‘thread thread-id
’ before or
after the breakpoint condition, like this:
(gdb) break frik.c:13 thread 28 if bartab > lim
Thread-specific breakpoints are automatically deleted when GDB detects the corresponding thread is no longer in the thread list. For example:
(gdb) c Thread-specific breakpoint 3 deleted - thread 28 no longer in the thread list.
There are several ways for a thread to disappear, such as a regular
thread exit, but also when you detach from the process with the
detach
command (see Debugging an Already-running
Process), or if GDB loses the remote connection
(see Remote Debugging), etc. Note that with some targets,
GDB is only able to detect a thread has exited when the user
explictly asks for the thread list with the info threads
command.
Next: Interrupted System Calls, Previous: Background Execution, Up: Thread Stops [Contents][Index]