This is the mail archive of the frysk@sources.redhat.com mailing list for the frysk project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: System call number cached with help from SyscallObserver



If syscall number is saved in updateSyscallEnter() in SyscallObserver,
all the classes that implement updateSyscallEnter() should be aware of
this details, and save the syscall number by themselves. It is not
good, since every time, when we implement updateSyscallEnter(), we
should save the syscall number by ourselves.(Correct me if I am wrong)

After today's discussion I tried locally caching the syscall in the updateSyscallEnter to reuse in updateSyscallExit. I did this in the ui implementation of the Sys call observer to see if we could get around concerns with how we dealt with exceptions. As it turns out, doing this in the interface won't work as SyscallEventInfo makes it own syscall "call" in:


arg = syscallEventInfo.returnCode(task);

where returnCode calls:

public long returnCode (Task task)
 {
   return getSyscall(task).getReturnCode(task);
 }

(Tom pointed out the above, btw, after I mentioned with even a locally cached syscall, I was still seeing the same errors.)
IMO, SyscallEventInfo is the good place to cache system call number,
and provides a method number(Task task, Boolean enterSyscall), which
return the system call number and cache it when enterSyscall is true,
while return the cached syscall number when enterSyscall is false.
The current number(Task) return system call number *always* from a
certain register.

So unless we re-architect how syscallEventInfo works a little bit, then right now caching there is the only way I can see.

Regards

Phil



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]