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

[Phil Muldoon <pmuldoon at redhat dot com>]

Mark Wielaard wrote:
> debugStatus & (1L << index)) != 0;
>
> where debug status is the debug status register,  and index is the 
> watchpoint to check.
>   
>
> 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? As there already is a general function implemented:

int getWatchpointCount()

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 ;)

Regards

Phil

> >  Should the bit be reset in hasWatchpointTriggered? 
> > Or in a separate function function called as a separate API?
> >     
>
> A separate method is cleaner. The problem I had with that (in the
> stepping flag) is that it then becomes somewhat harder to know when to
> clear the status flags. Since the state machine is guaranteed to check
> the status before any state transitions it is somewhat easier to make it
> a check-and-clear-status method:
> http://sourceware.org/ml/frysk/2007-q1/msg00024.html
> If you have a separate method you can either call it directly after
> checking the status, or in the Running.sendContinue() method. I
> introduced this to have one point in the ptrace state machine where a
> Task is set running again:
> http://sourceware.org/ml/frysk/2007-q2/msg00329.html
> We also already discussed basing the stepping flag on this new
> infrastructure: http://sourceware.org/ml/frysk/2007-q3/msg00324.html
> (And I agreed it would be somewhat cleaner than what is done now.)
>
>   

Ok I'll look at what goes on here. 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?

Thanks!

Regards

Phil
> Cheers,
>
> Mark
>
>