Re: System call number cached with help from SyscallObserver

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Yao" == Yao Qi <qiyaoltc@cn.ibm.com> writes:

Yao> 1) add a new member syscallNumber in SyscallEventInfo to
Yao> cache the system call number.
Yao> 2) add a new method getSyscall(Task task, boolean enterSyscall) to
Yao> differentiate it is called by updateSyscallEnter or updateSyscallExit.

This strikes me as an awkward API.

Wouldn't user code see this same bug if it called the new getSyscall
only in the exit handler?

I think there are 2 potential solutions that would yield a nicer user
experience.

First, and simplest, just require the system call number to be
discovered when the SyscallEventInfo object is created.  E.g.:

    private final syscallNumber;
    protected SyscallEventInfo(Task task) {
      syscallNumber = number(task);
    }

... then make other needed changes like updating subclass
constructors, making 'number' protected, adding a new accessor for
users, etc.  Or instead of caching the number you could look up and
cache the actual Syscall object; same difference.

This plan only works if a SyscallEventInfo is created when a syscall
is entered, otherwise the lookups won't work.

If that isn't always the case, or if the cost of this lookup is too
high, then another plan would be to have two kinds of SyscallEventInfo
objects -- one used on entry and one on exit.  This seems a bit tricky
since getReturnCode relies on getting the syscall number, at the moment.

What do you think of this?

Tom