Re: How to handle Clone/Fork/Exec when traceSyscall is true

[Sami Wagiaalla <swagiaal at redhat dot com>]

Sami Wagiaalla wrote:
> Hi Yao,
>
> I have recently started working on systemcall tracing so i am not an 
> expert but
> i can answer some of your concerns :)
> > At present(06/08/2006), to set tracing syscall, the Task requires that
> > traceSyscall boolean be set to true.  When a task is continued via 
> > sendContinue (), if the traceSyscall is true, PTRACE_SYSCALL is
> > used instead of using PTRACE_CONT.
> >   
> I have changed that (although not committed yet). In my code the Task 
> state machine
> handles the transition into syscall tracing mode. The boolean has been 
> eliminated
> ptrace options are set when syscall states are entered, and all 
> continues are replaced
> with syscallContinues.

That code is now in cvs. traceSyscalls = true is forever gone :D
> > The problem is that, take EXECVE syscall for example, the wait logic
> > will deliver SyscallEvent(Enter EXECVE Syscall) before ExecedEvent, and
> > then deliver SyscallEvent(Exit EXECVE Syscall), when traceSyscall is
> > true.  In current Task State Machine, ExecedEvent could not be handled
> > when StateMachine is in state "runningInSyscall".
> >
> > If I enable testI386Regs, and set task.traceSyscall to true, the error
> > could be seen as follows,
> >
> > Time: 0.313
> > There was 1 error:
> > 1) testI386Regs(frysk.proc.TestI386Regs)java.lang.RuntimeException:
> > {frysk.proc.LinuxTask@226870,pid=21048,tid=21048,state=runningInSyscall}
> > in state "runningInSyscall" did not handle handleExecedEvent
> >
> > At first, I doubt that this problem is caused by Task State Machine,
> > and try to override handleExecedEvent in runningInSyscall, and then I
> > realize that it is not a good solution to this problem, so I give up
> > on this way.
I have commited code that uses that strategy to fix the the problem. 
Please take a look
and let me know what you think :)