From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3496 invoked by alias); 2 Apr 2008 10:54:16 -0000 Received: (qmail 3485 invoked by uid 22791); 2 Apr 2008 10:54:15 -0000 X-Spam-Status: No, hits=-2.6 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; Wed, 02 Apr 2008 10:53:55 +0000 Received: from cc1341701-a.deven1.ov.home.nl ([82.72.53.253]) by gnu.wildebeest.org with esmtp (Exim 4.63) (envelope-from ) id 1Jh0bG-0000kd-LC; Wed, 02 Apr 2008 12:53:52 +0200 Subject: Re: [SCM] master: Implement hasWatchpointTriggered in abstract, and sub-classes. From: Mark Wielaard To: Phil Muldoon Cc: frysk@sourceware.org In-Reply-To: <47F34972.8080403@redhat.com> References: <20080401204912.27374.qmail@sourceware.org> <47F2A1E1.1070404@redhat.com> <1207122509.4953.27.camel@cc1341701-a.deven1.ov.home.nl> <47F34972.8080403@redhat.com> Content-Type: text/plain Date: Wed, 02 Apr 2008 10:54:00 -0000 Message-Id: <1207133630.4953.48.camel@cc1341701-a.deven1.ov.home.nl> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-3.fc8) Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) 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-q2/txt/msg00009.txt.bz2 Hi Phil, On Wed, 2008-04-02 at 09:53 +0100, Phil Muldoon wrote: > Mark Wielaard wrote: > > I think this is a little too architecture specific and a little error > > prone in usage. Code using this now has to iterate over all the possible > > watchpoint indexes for a particular architecture. Maybe this is small > > and trivial on all architectures, but it would feel more natural imho if > > there was just a method to query which watchpoint index was triggered if > > any. Something like: > > > > public abstract int watchpointTriggered(Task task); > > Originally I did have something like this, but it does not answer the > scenario of what happens when a sigtrap is delivered that denotes > multiple watchpoints being triggered? There's no real clean way to do > this per architecture. Could return an array of .. perhaps booleans > denoting each register as being triggered, or maybe a list of .. same > again, what? If so then I would return a Set of the actual watchpoints (just return the address, range and mode [read/write]) that triggered instead of the index (or null of course if no watchpoint was triggered). That would need a little container class that holds these values. The benefit is that it would abstract away any architecture specific implementation details (like the index and whether or not this is done with specific cpu support or not). And that you can easily store them in a Collection that you can then return from a method like this. > the user can iterate over the watchpoints themselves in a simple loop. > If you can make watchpointTriggered work so it accounts for multiple > watchpoints hit, I'll be happy ;) Could you show some scenarios where higher level constructs get mapped onto overlapping watchpoints (which cannot be compressed into non-overlapping ones) or instructions which can trigger multiple hardware watchpoints at once? It seems like things become simpler if we only have to worry about one hardware watchpoint triggering at any given moment. But maybe there are valid scenarios where multiple watchpoints trigger at the same time (in that case, do you really care which one?) > The second half of the question is, > how and by what mechanism do you allow the user to continue a task. By > default the task is stopped and will stay stopped until such a time that > the user is done inspecting the environment. How will the user restart > the task? The user doesn't explicitly restart the task, the task just transforms into a Running (sub) state that triggers a continueRunning() whenever all blockers are removed (or no blockers were ever introduced in the first place). Cheers, Mark