From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2224 invoked by alias); 4 Oct 2013 18:26:59 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 2211 invoked by uid 89); 4 Oct 2013 18:26:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 04 Oct 2013 18:26:57 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r94IQs5J020148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Oct 2013 14:26:55 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r94IQrt3032171; Fri, 4 Oct 2013 14:26:54 -0400 Message-ID: <524F086C.3030908@redhat.com> Date: Fri, 04 Oct 2013 18:26:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Eli Zaretskii CC: gdb-patches@sourceware.org Subject: Re: [PATCH] [DOC] Mention what happens when the thread of a thread-specific breakpoint is gone. References: <1380898896-16767-1-git-send-email-palves@redhat.com> <83y569apvb.fsf@gnu.org> <524F00E6.9010104@gmail.com> <524F01E4.7050902@redhat.com> In-Reply-To: <524F01E4.7050902@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-10/txt/msg00152.txt.bz2 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 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