OpenE2K
/
binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

[DOC] Mention what happens when the thread of a thread-specific breakpoint disappears. 

We recently made GDB auto-delete thread-specific breakpoints when the
corresponding thread is removed from the thread list, but we hadn't
mentioned it in the manual.

gdb/
2013-10-07  Pedro Alves  <palves@redhat.com>

	PR breakpoints/11568
	* gdb.texinfo (Thread-Specific Breakpoints): Mention what happens
	when the thread is removed from the thread list.
This commit is contained in:
Pedro Alves 2013-10-07 11:13:08 +00:00
parent 46ecd52745
commit f4fb82a127
2 changed files with 24 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
gdb/doc/ChangeLog
View File

@ -1,3 +1,9 @@
2013-10-07 Pedro Alves <palves@redhat.com>
PR breakpoints/11568
* gdb.texinfo (Thread-Specific Breakpoints): Mention what happens
when the thread is removed from the thread list.
2013-10-06 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.texinfo (Convenience Variables): Document $_exitsignal.

18
gdb/doc/gdb.texinfo
View File

@ -5864,6 +5864,24 @@ after the breakpoint condition, like this:
@end table
Thread-specific breakpoints are automatically deleted when
@value{GDBN} detects the corresponding thread is no longer in the
thread list. For example:
@smallexample
(@value{GDBP}) c
Thread-specific breakpoint 3 deleted - thread 28 no longer in the thread list.
@end smallexample
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
@code{detach} command (@pxref{Attach, ,Debugging an Already-running
Process}), or if @value{GDBN} loses the remote connection
(@pxref{Remote Debugging}), etc. Note that with some targets,
@value{GDBN} is only able to detect a thread has exited when the user
explictly asks for the thread list with the @code{info threads}
command.
@node Interrupted System Calls
@subsection Interrupted System Calls