From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25129 invoked by alias); 2 Aug 2013 09:45:15 -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 25118 invoked by uid 89); 2 Aug 2013 09:45:15 -0000 X-Spam-SWARE-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_05,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 02 Aug 2013 09:45:15 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r729j6Gx031700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Aug 2013 05:45:06 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r729j2ZQ024326; Fri, 2 Aug 2013 05:45:03 -0400 Message-ID: <51FB7F9E.30701@redhat.com> Date: Fri, 02 Aug 2013 09:45: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: Muhammad Waqas CC: Yao Qi , gdb-patches@sourceware.org, tromey@redhat.com, ali_anwar@codesourcery.com Subject: Re: [PATCH with testcase] Bug 11568 - delete thread-specific breakpoint on the thread exit References: <51F619CE.5040407@codesourcery.com> <51F633E5.7000302@codesourcery.com> <51F65519.2080806@codesourcery.com> <51F67992.30704@codesourcery.com> <51F7967E.3060900@codesourcery.com> <51FA4D21.4000309@redhat.com> <51FA5806.7050505@codesourcery.com> In-Reply-To: <51FA5806.7050505@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-08/txt/msg00066.txt.bz2 On 08/01/2013 01:43 PM, Muhammad Waqas wrote: >>> >> + || !target_thread_alive (tp->ptid))) >>> >> + if ( tp != NULL && (tp->state == THREAD_EXITED >>> >> + || !target_thread_alive (tp->ptid))) >> > Do we really need this target_thread_alive call? It >> > means we have extra remote traffic whenever we have a thread >> > specific breakpoint in the list. If the user (or GDB itself) >> > hasn't refreshed the thread list, is there any harm in delaying >> > deleting the breakpoint? >> > >> > But, I think I agree with Yao in that this doesn't look like >> > the right way to do this. >> > >> > In fact, breakpoint_auto_delete is only called when the >> > target reports some stop. If you're trying to delete >> > stale thread specific breakpoints, then you'd want to >> > do that even if the target hasn't reported a stop, right? >> > >> > Say, in non-stop mode, w/ the remote target, if you have two >> > threads, set a thread-specific break on thread 2, and while >> > all threads are running free in busy loops, not reporting >> > any event, keep doing "info threads", and "info break". At some >> > point thread #2 exits. You can see that from "info threads". >> > But "info break" will still show you the stale breakpoint... > If breakpoint will be deleted when thread list is updated through > user or GDB and also when info break command is executed > by user, Will it work? What will you say about this technique? > I wouldn't even consider special casing "info break". Otherwise, you end up considering whether to handle all sorts of breakpoint manipulation commands, like "enable", "disable", etc., and what to do if the thread is already gone. Tie this to GDB's own lifetime of the inferior's threads. If GDB learns the thread is gone, remove the breakpoint. Otherwise, leave it there. Whether to remove the breakpoint immediately, or mark it as disp_del_at_next_stop (and hide it, say, set its bp->num to 0) is another question. You'll note that clear_thread_inferior_resources does the latter. (That's because most of GDB's native targets can't touch memory of running processes.) -- Pedro Alves