Thread-Specific Breakpoints (Debugging with ROCGDB)

Next: Interrupted System Calls, Previous: Background Execution, Up: Thread Stops [Contents][Index]

#### 5.5.4 Thread-Specific Breakpoints

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 ROCGDB to stop the program when a particular thread reaches this breakpoint. The thread-id specifier is one of the thread identifiers assigned by ROCGDB, 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 ROCGDB 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 ROCGDB loses the remote connection (see Remote Debugging), etc. Note that with some targets, ROCGDB 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]