From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10490 invoked by alias); 26 Feb 2008 16:25:14 -0000 Received: (qmail 10477 invoked by uid 22791); 26 Feb 2008 16:25:14 -0000 X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (83.160.170.119) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 26 Feb 2008 16:24:56 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 4.63) (envelope-from ) id 1JU2bt-00049g-9W; Tue, 26 Feb 2008 17:24:53 +0100 Subject: Re: Watchpoint prorogation to child threads From: Mark Wielaard To: Phil Muldoon Cc: Frysk Hackers In-Reply-To: <47C43A38.4030407@redhat.com> References: <47C42CA3.1030003@redhat.com> <1204041610.3487.62.camel@dijkstra.wildebeest.org> <47C43A38.4030407@redhat.com> Content-Type: text/plain Date: Tue, 26 Feb 2008 16:25:00 -0000 Message-Id: <1204043093.3487.78.camel@dijkstra.wildebeest.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2008-q1/txt/msg00079.txt.bz2 Hi Phil, On Tue, 2008-02-26 at 16:11 +0000, Phil Muldoon wrote: > Mark Wielaard wrote: > > It would be nice if this is similar to the breakpoints. Low-level > > breakpoints are the same on a clone (because they are really just > > markers in the code segment which is the same), but they are cleared on > > exec (because then the memory of the process is reset). > > I'm not sure I understand, are breakpoints propagated on clone or not? I > think they should, and I think I agree on the similarity. Yes, the low-level breakpoints are propagated (by virtue of them being actually inside the code segment that are shared between clones). But higher-level Code observers still work per Task, so on that level you need to register a new Code observer for a new Task to get notified when they trigger (they still trigger of course, but if nobody is listening...). I assume a Watch is similar to a Code, both being TaskObservers (and the comments look funnily similar). > To be honest, not thought about the exec issue, but yeah I guess the > memory is reset. The memory is, and for low-level breakpoints we reset the internal data structures for that reason on an exec event. Since you are implementing low-level watchpoints with hardware support in the cpu register you might have to also clear those (if the kernel doesn't do that for you on an exec). Cheers, Mark