Re: [SCM] master: Implement hasWatchpointTriggered in abstract, and sub-classes.

[Mark Wielaard <mark@klomp.org>]

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