TaskState handleTrappedEvent

TaskState handleTrappedEvent

[Phil Muldoon]

I noticed that this state is getting a little more crowded and will be 
even more crowded soon with watchpoints. 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.

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?

Regards

Phil

Re: TaskState handleTrappedEvent

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 2844 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: TaskState handleTrappedEvent

[Phil Muldoon]

Mark Wielaard wrote:
> 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.
>   

What's a synthetic event?

>   
>> 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. 

So to be clear several events can occur, that will only result in one 
sigtrap operation? So it becomes a pass-along affair; each little 
sub-system lints their respective status areas and if not for them, 
"passes" the trap along.

I suppose what worries me is precedence and preservation. Say two events 
occurs but one sigtrap is generated. The first consumers see that it is 
for them, does it then continue to pass that along? Does this existing 
code do this now? All all sigtraps always passed along to the task at 
the end? Should they?

Regards

Phil

Re: TaskState handleTrappedEvent

[Mark Wielaard]

Hi Phil,

On Tue, 2007-10-30 at 15:47 +0000, Phil Muldoon wrote:
> Mark Wielaard wrote:
> > 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.
> >   
> What's a synthetic event?

A 'frysk core' generated event, unlike a ptrace generated event.
See for example LinuxWaitBuilder.stopped() and
saveFsckedOrderedKernelStoppedEvent() where we either transform the
original event into a different one or reschedule the events a little
before delivering to the next layer.

> > Ideally we get an different event for different things. Since we
> > currently don't we have some (arbitrary) order. 
> 
> So to be clear several events can occur, that will only result in one 
> sigtrap operation? So it becomes a pass-along affair; each little 
> sub-system lints their respective status areas and if not for them, 
> "passes" the trap along.

Yes, in handleTrappedEvent() we currently do this by checking some extra
state (if isa.isTaskStepped() returns true or the pc is right at a
software breakpoint instruction which we inserted ourselves and we are
currently stepping that instruction, we assume it is a real step and
call task.notifyInstruction(), else we assume it is a breakpoint event
and call task.notifyCodeObserver() if that return -1 (no breakpoint
inserted here by us) then we assume it is a trap signal event and call
handleSignaledEvent(). As you said, it would be better to abstract this
logic out a bit instead of having this if-then-else chain.

> I suppose what worries me is precedence and preservation. Say two events 
> occurs but one sigtrap is generated. The first consumers see that it is 
> for them, does it then continue to pass that along? Does this existing 
> code do this now? All all sigtraps always passed along to the task at 
> the end? Should they?

On x86/x86_64 you should be able to detect the right variant through the
debug status register, that then gives you the precedence order to
check. But till now we have only dealt with one case (the step flag) and
assumed it isn't set if any other reason for the trap event triggers. So
you are entering new territory.

If in doubt I am afraid you need to write some testcases simulating
different events that all generate a trap event at the same time and
look at which get through (and what debug flags are set).

Cheers,

Mark