From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5649 invoked by alias); 11 May 2013 09:10: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 5630 invoked by uid 89); 11 May 2013 09:10:58 -0000 X-Spam-SWARE-Status: No, score=-8.4 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Sat, 11 May 2013 09:10:58 +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 r4B9AroL015815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 May 2013 05:10:53 -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 r4B9AprA029130; Sat, 11 May 2013 05:10:52 -0400 Message-ID: <518E0B1B.3000403@redhat.com> Date: Sat, 11 May 2013 09:10:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Philippe Waroquiers CC: Doug Evans , gdb-patches Subject: Re: RFA: fix gdb_assert caused by 'catch signal ...' and fork References: <1368136582.30058.7.camel@soleil> <518D2BF4.6090401@redhat.com> <1368224079.2230.49.camel@soleil> In-Reply-To: <1368224079.2230.49.camel@soleil> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg00406.txt.bz2 On 05/10/2013 11:14 PM, Philippe Waroquiers wrote: > On Fri, 2013-05-10 at 18:18 +0100, Pedro Alves wrote: >> On 05/10/2013 05:39 PM, Doug Evans wrote: >>> However, there's nothing in "bp_loc_other" that says we should always >>> continue there. >>> Other breakpoint kinds are marked bp_loc_other too. >> >> The other breakpoint kinds (software watchpoints, catchpoints, >> tracepoints) don't require detaching. The state of bp_loc_other >> breakpoints, at least at present, is always on the GDB side. >> Detaching is required for those breakpoints that is assumed >> get auto-cloned by the target/kernel to forked children. >> >>> Plus avoiding calling remove_breakpoint_1 feels like working around the problem. >>> This doesn't feel like the right fix. >> >> GDB doesn't have an inferior or any other state corresponding >> to the process whose breakpoints are being detached. >> >> An alternative I imagine would be something like adding >> "detach breakpoint" target methods (and bl->owner->ops->detach_location, >> etc.) and call that instead of remove_breakpoint_1, though it >> seems like we'd get the same result (with the present state). But >> I won't object to trying that. > I do not master much of breakpoint.h/.c but it looks to > me that this implies to add quite some code which will > at the end either do nothing (for bp_loc_other) or > call remove_breakpoint_1 (for others). Not exactly remove_breakpoint_1, but something like it, that ends up calling (a new) target_detach_breakpoint. > What would be the advantages of the detach_breakpoint > and detach_location target methods ? It'd be one way forward if we actually needed to detach some kind of catchpoint, while not others. Note the idea wasn't that much cooked, I'd leave that to whoever attempts to implement it. It could end up being the target method wouldn't be necessary. The gist would be to use breakpoint_ops dispatching somehow instead of explicit type checks. Or maybe some other deeper design change would be better. Changing how core gdb reacts to forks throughout, making it have an inferior for the new fork sooner comes to mind. I don't have a substantially formed idea of what that would be the ideal design, and I can't afford spending hours/days investigating this myself at the moment, unfortunately. > As long as there is no need (yet) for a different "detach" > behaviour depending on specialised bp_location, it looks > to me that the single "if" is simpler and corresponds to > the description of detach_breakpoints in breakpoint.h. Right, that was my reasoning for suggesting going with the location type originally. -- Pedro Alves