[PATCH] [DOC] Mention what happens when the thread of a thread-specific breakpoint is gone.

[PATCH] [DOC] Mention what happens when the thread of a thread-specific breakpoint is gone.

[Pedro Alves]

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

OK?

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

	PR breakpoints/11568
	* gdb.texinfo (Thread-Specific Breakpoints): Mention what happens
	when the thread is gone.
---
 gdb/doc/gdb.texinfo | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index a68556b..97b0aff 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -5864,6 +5864,14 @@ after the breakpoint condition, like this:
 
 @end table
 
+Thread-specific breakpoints are automatically deleted when
+@value{GDBN} detects the corresponding thread is gone.  For example:
+
+@smallexample
+(@value{GDBP}) c
+Thread-specific breakpoint 3 deleted - thread 28 is gone.
+@end smallexample
+
 @node Interrupted System Calls
 @subsection Interrupted System Calls 
 
-- 
1.7.11.7

Re: [PATCH] [DOC] Mention what happens when the thread of a thread-specific breakpoint is gone.

[Eli Zaretskii]

> From: Pedro Alves <palves@redhat.com>
> Date: Fri,  4 Oct 2013 16:01:36 +0100
> 
> We recently made GDB auto-delete thread-specific breakpoints when the
> corresponding thread is gone, but we haven't mentioned it in the manual.
> 
> OK?

Yes, thanks.  One nit, though:

> +Thread-specific breakpoints are automatically deleted when
> +@value{GDBN} detects the corresponding thread is gone.
                                          ^^^^^^^^^^^^^^
I'd say "thread exits" instead.

Re: [PATCH] [DOC] Mention what happens when the thread of a thread-specific breakpoint is gone.

[Pedro Alves]

On 10/04/2013 06:48 PM, Eli Zaretskii wrote:
>> From: Pedro Alves <palves@redhat.com>
>> Date: Fri,  4 Oct 2013 16:01:36 +0100
>>
>> We recently made GDB auto-delete thread-specific breakpoints when the
>> corresponding thread is gone, but we haven't mentioned it in the manual.
>>
>> OK?
> 
> Yes, thanks.  One nit, though:
> 
>> +Thread-specific breakpoints are automatically deleted when
>> +@value{GDBN} detects the corresponding thread is gone.
>                                           ^^^^^^^^^^^^^^
> I'd say "thread exits" instead.

That was on purpose.  It's what GDB says too.  That's because
there are other ways for a thread to disappear other than
a regular thread exit, such as "detach", "disconnect"
or gdb losing the remote connection, etc.  The thread hasn't
really exited in those cases.

-- 
Pedro Alves

Re: [PATCH] [DOC] Mention what happens when the thread of a thread-specific breakpoint is gone.

[Pedro Alves]

On 10/04/2013 06:54 PM, Pedro Alves wrote:
> That was on purpose.  It's what GDB says too.  That's because
> there are other ways for a thread to disappear other than
> a regular thread exit, such as "detach", "disconnect"
> or gdb losing the remote connection, etc.  The thread hasn't
> really exited in those cases.

I guess that means I should update the docs to clarify that.  :-)
A sec while I prepare a new patch.

-- 
Pedro Alves

Re: [PATCH] [DOC] Mention what happens when the thread of a thread-specific breakpoint is gone.

[Pedro Alves]

On 10/04/2013 06:59 PM, Pedro Alves wrote:
> On 10/04/2013 06:54 PM, Pedro Alves wrote:
>> That was on purpose.  It's what GDB says too.  That's because
>> there are other ways for a thread to disappear other than
>> a regular thread exit, such as "detach", "disconnect"
>> or gdb losing the remote connection, etc.  The thread hasn't
>> really exited in those cases.
> 
> I guess that means I should update the docs to clarify that.  :-)
> A sec while I prepare a new patch.

What about this?  I'm now saying "no longer in the thread list"
instead of "is gone".

Not sure whether GDB's own wording should be changed in the
same way?  This is 78 columns:

-Thread-specific breakpoint 3 deleted - thread 28 is gone.
+Thread-specific breakpoint 3 deleted - thread 28 no longer in the thread list.

It'll of course be larger with higher breakpoint and thread numbers, but
I guess it is still within reasonable bounds...

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

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

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

	PR breakpoints/11568
	* gdb.texinfo (Thread-Specific Breakpoints): Mention what happens
	when the thread is gone.
---

 gdb/doc/gdb.texinfo |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index a68556b..207a93e 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -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 is gone.
+@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 
 

Re: [PATCH] [DOC] Mention what happens when the thread of a thread-specific breakpoint is gone.

[Eli Zaretskii]

> Date: Fri, 04 Oct 2013 19:26:52 +0100
> From: Pedro Alves <palves@redhat.com>
> CC: gdb-patches@sourceware.org
> 
> On 10/04/2013 06:59 PM, Pedro Alves wrote:
> > On 10/04/2013 06:54 PM, Pedro Alves wrote:
> >> That was on purpose.  It's what GDB says too.  That's because
> >> there are other ways for a thread to disappear other than
> >> a regular thread exit, such as "detach", "disconnect"
> >> or gdb losing the remote connection, etc.  The thread hasn't
> >> really exited in those cases.
> > 
> > I guess that means I should update the docs to clarify that.  :-)
> > A sec while I prepare a new patch.
> 
> What about this?  I'm now saying "no longer in the thread list"
> instead of "is gone".

This is good, thanks.

> Not sure whether GDB's own wording should be changed in the
> same way?  This is 78 columns:
> 
> -Thread-specific breakpoint 3 deleted - thread 28 is gone.
> +Thread-specific breakpoint 3 deleted - thread 28 no longer in the thread list.
> 
> It'll of course be larger with higher breakpoint and thread numbers, but
> I guess it is still within reasonable bounds...

Maybe we should change the message wording as well; "gone" sounds
awfully like "dead", which is inaccurate, and might even surprise the
user if the thread actually simply exited.

Thread-specific breakpoints: say "no longer in the thread list" instead of "gone". (was: [PATCH] [DOC] Mention what happens when the thread of a thread-specific breakpoint is gone.)

[Pedro Alves]

On 10/04/2013 08:20 PM, Eli Zaretskii wrote:

> Pedro Alves wrote:
>> Not sure whether GDB's own wording should be changed in the
>> same way?  This is 78 columns:
>>
>> -Thread-specific breakpoint 3 deleted - thread 28 is gone.
>> +Thread-specific breakpoint 3 deleted - thread 28 no longer in the thread list.
>>
>> It'll of course be larger with higher breakpoint and thread numbers, but
>> I guess it is still within reasonable bounds...
> 
> Maybe we should change the message wording as well; "gone" sounds
> awfully like "dead", which is inaccurate, and might even surprise the
> user if the thread actually simply exited.

OK, thanks.  I've applied a patch that changes GDB's wording like above.

---------
Thread-specific breakpoints: say "no longer in the thread list" instead of "gone".

It seems "gone" may confuse people, while that was exactly what it was
trying to avoid.  Switch to saying "no longer in the thread list",
which is really the predicate GDB uses.

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

	PR breakpoints/11568
	* breakpoint.c (remove_threaded_breakpoints): Say "no longer in
	the thread list" instead of "gone".
---

 gdb/breakpoint.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index b98ca9e..d3e9e49 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -2943,7 +2943,7 @@ remove_threaded_breakpoints (struct thread_info *tp, int silent)
 	  b->disposition = disp_del_at_next_stop;
 
 	  printf_filtered (_("\
-Thread-specific breakpoint %d deleted - thread %d is gone.\n"),
+Thread-specific breakpoint %d deleted - thread %d no longer in the thread list.\n"),
 			  b->number, tp->num);
 
 	  /* Hide it from the user.  */

Re: [PATCH] [DOC] Mention what happens when the thread of a thread-specific breakpoint is gone.

[Pedro Alves]

On 10/04/2013 08:20 PM, Eli Zaretskii wrote:
>> From: Pedro Alves <palves@redhat.com>

>> What about this?  I'm now saying "no longer in the thread list"
>> instead of "is gone".
> 
> This is good, thanks.

Thanks.  Applied, with the small example adjusted to gdb's new output.

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

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.
---

 gdb/doc/gdb.texinfo |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 7ec91d8..e196658 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -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

Re: [PATCH] [DOC] Mention what happens when the thread of a thread-specific breakpoint is gone.

[Eli Zaretskii]

> Date: Fri, 04 Oct 2013 18:54:46 +0100
> From: Pedro Alves <alves.ped@gmail.com>
> CC: Pedro Alves <palves@redhat.com>, gdb-patches@sourceware.org
> 
> >> +Thread-specific breakpoints are automatically deleted when
> >> +@value{GDBN} detects the corresponding thread is gone.
> >                                           ^^^^^^^^^^^^^^
> > I'd say "thread exits" instead.
> 
> That was on purpose.  It's what GDB says too.  That's because
> there are other ways for a thread to disappear other than
> a regular thread exit, such as "detach", "disconnect"
> or gdb losing the remote connection, etc.  The thread hasn't
> really exited in those cases.

Then let's mention those other possibilities as well.  "Is gone" is
too vague and too slang.