Hi Phil,

On Wed, 2007-10-24 at 16:09 +0100, Phil Muldoon wrote:
> I noticed that this state is getting a little more crowded and will be 
> even more crowded soon with watchpoints.

Yes, this comes from ptrace/wait translating all events into trap
signals. I tried to split things a little by having a separate stepping
state, but it is better to split up the trapped events into separate
(synthetic) events (see below) and then cross-checking with Chris and
Roland to make sure a future utrace layer gives us similar, but truly
separate events, with the same semantics.

> Before I add my own patches 
> here, some questions:
> 
> 1) Is there an important order precedence here? Must it handle single 
> step over breakpoints over watchpoints in any particular order? I can't 
> think of why the order matters.

Ideally we get an different event for different things. Since we
currently don't we have some (arbitrary) order. Currently we explictly
first check to see if the Task got just started, then whether we are
currently on top of a breakpoint instruction, and finally whether the
Isa indicates the current trapped event is a stepepd event. See
Isa.isTaskStepped(Task), Task.steppingBreakpoint and Task.just_started
in handleTrappedEvent. It might make sense to push these checks into
LinuxWaitBuilder.stopped() where we already split out events for
Stopped, Trapped and Signaled. There are also two other checks at the
end to see whether or not the trapped event is an actual trap signal or
something else (that we discard). See Isa.hasExecutedSpuriousTrap(Task)
and task.syscall_sigret.

> 2) I'm a little fuzzy on if there were will be an opportunity for 
> multiple events to happen on a single sigtrap (ie breakpoint and 
> watchpoint). I cannot think of any  right now other than single step 
> writing something to a memory address that the watchpoint is monitoring, 
> but that should be caught on as another later sigtrap. Are there 
> opportunities for multiple events? If so, are there any precedence issues?

Yes, at the moment stepping just assumes every trap event is an
important event for an Instruction observer, so we just report them all
(and this seems necessary since stepping onto a trapping instruction,
like a breakpoint, or receiving a signal, seem to trump the actual
stepping trap event). It is up to the actual Instruction observer to
check whether the event was really important as a "step", we could in
theory do this by checking the pc value between trap events, but that
quickly becomes messy when taking instructions into account that jump to
the same pc location. So in practise an TaskObserver.Instruction
updateHit() means something, most likely an instruction step, happened
that changed the state of the Task under observation.

Cheers,

Mark