System call number cached with help from SyscallObserver

System call number cached with help from SyscallObserver

[Yao Qi]

It is not *always* right to get system call number from a certain
register when exit from a system call, such as rt_sigreturn.  This
problem has been discussed in this thread,

http://sources.redhat.com/ml/frysk/2006-q3/msg00305.html

Andrew explained that *all* the registers have been flushed to restore
the state of that thread, so "orig_eax"(ia32), "orig_rax"(x86_64) or
"gpr0"(ppc) does not contain the value of system call number any more.

And I could also find that there is a problem caused by this in IRC log,

<npremji> pmuldoon, I'm getting some issues with bash and syscalls
<pmuldoon> npremji: I'm building now, but what issues?
<npremji> a bunch of negative syscall number java runtime exceptions
<npremji> java.lang.RuntimeException: Negative Syscall Number:-1
<npremji>    at frysk.proc.Syscall.syscallByNum(FryskGui)
<npremji>    at frysk.proc.LinuxIa32Syscall.syscallByNum(FryskGui)
<npremji>    at frysk.proc.LinuxIa32$1.getSyscall(FryskGui)
<npremji>    at
frysk.gui.monitor.observers.SysCallUtilyInfo.getReturnInfoFromSyscall(FryskGui)
<npremji>    at
frysk.gui.monitor.observers.TaskSyscallObserver.exitBottomHalf(FryskGui)
<npremji>    at
frysk.gui.monitor.observers.TaskSyscallObserver$2.run(FryskGui)
<npremji>    at org.gnu.glib.CustomEvents.runEvents(libgtkjava-2.8.so)
<npremji>    at org.gnu.gtk.Gtk.gtk_main(libgtkjava-2.8.so)
<pmuldoon> npremji: probably from the Sycall checkin last night
<npremji>    at org.gnu.gtk.Gtk.main(libgtkjava-2.8.so)
<npremji>    at frysk.gui.Gui.gui(FryskGui)
<npremji>    at frysk.gui.FryskGui.main(FryskGui)

It is not the fault for Syscall to check the range of system call
number, but the wrong value when we want to get the system call number
from a register.

The only thing I could figure out to fix this problem is to add a
SyscallObserver to update system call number cached in
SyscallEventInfo, or some where else, when enter in a system call, and
return system call numbers to other objects that want to know system
call information. (Any other solutions, free to tell me)
However, some requirements are needed here,

1) This SyscallObserver should be notified first when a syscall come
in to update system call number, and other observers will get system
call number from the cached value later.  How to make this 
SyscallObserver to be the first?

2) This SyscallObserver could not be added if no other "clients" add
SyscallObserver for themselves.  If no one add SyscallObserver, we do
not need add SyscallObserver to update system call number also.

That is to say, this SyscallObserver for system call number update
should be added firstly if other "clients", such as ftrace or UI,
want to add their SyscallObservers.

Any comments?  Thanks in advance!

-- 
Yao Qi

Re: System call number cached with help from SyscallObserver

[Mark Wielaard]

Hi Yao,

On Fri, 2006-09-15 at 15:05 +0800, Yao Qi wrote:
> It is not *always* right to get system call number from a certain
> register when exit from a system call, such as rt_sigreturn.  This
> problem has been discussed in this thread,
> 
> http://sources.redhat.com/ml/frysk/2006-q3/msg00305.html
> 
> Andrew explained that *all* the registers have been flushed to restore
> the state of that thread, so "orig_eax"(ia32), "orig_rax"(x86_64) or
> "gpr0"(ppc) does not contain the value of system call number any more.
> 
> [...]
>
> The only thing I could figure out to fix this problem is to add a
> SyscallObserver to update system call number cached in
> SyscallEventInfo, or some where else, when enter in a system call, and
> return system call numbers to other objects that want to know system
> call information. (Any other solutions, free to tell me)

SyscallObservers are all "equal", you cannot currently add one that has
preference over any of the others. But the Task or TaskState could hold
this info if needed.

What is precisely the use case? When does a SyscallObserver want to get
at the syscall number (or arguments) on exit? Can we assume that a
SyscallObserver will record Enter/Exit pairs themselves? If so then a
SyscallObserver should probably have saved the syscall number and any
arguments it is interested in on updateSyscallEnter() so it can use them
in updateSyscallExit(). Then when updateSyscallExit() is called the only
"valid" thing to query is the return value.

If the above is accurate then I think we can/should provide some support
inside the TaskState machinery. The TaskState should have an acurate
view of whether the Task is inside or outside a system call. What we
could add is a way for the TaskObserver.Syscall.updateSyscallEnter() to
indicate whether or not it is actually interested in updateSyscallExit()
being called.

For example by letting it return a Action CONTINUE_INTERESTED or
BLOCKED_INTERESTED. If any other Action is returned the observer will
not be called when the syscall exits.

That way we can make sure that updateSyscallExit() is only called for
any syscall that the observer is actually interested in. And if it is
interested then we can assume it will have saved the syscall number and
any arguments it is interested in itself and that the only thing that it
might want to query on exit is the return value.

Cheers,

Mark

Re: System call number cached with help from SyscallObserver

[Andrew Cagney]

Mark Wielaard wrote:
> For example by letting it return a Action CONTINUE_INTERESTED or
> BLOCKED_INTERESTED. If any other Action is returned the observer will
> not be called when the syscall exits.
>
>   

The sole purpose of of Action is to provide a mechanism that facilitates 
the implementation of both in-band and out-of-band handling of 
notifications.

Andrew

Re: System call number cached with help from SyscallObserver

[Mark Wielaard]

Hi Andrew,

On Fri, 2006-09-15 at 11:16 -0400, Andrew Cagney wrote:
> The sole purpose of of Action is to provide a mechanism that facilitates 
> the implementation of both in-band and out-of-band handling of 
> notifications.

What does that mean?
And what alternative do you suggest?

Cheers,

Mark

Re: System call number cached with help from SyscallObserver

[Andrew Cagney]

Mark Wielaard wrote:
> Hi Yao,
>
> On Fri, 2006-09-15 at 15:05 +0800, Yao Qi wrote:
>   
>> It is not *always* right to get system call number from a certain
>> register when exit from a system call, such as rt_sigreturn.  This
>> problem has been discussed in this thread,
>>
>> http://sources.redhat.com/ml/frysk/2006-q3/msg00305.html
>>
>> Andrew explained that *all* the registers have been flushed to restore
>> the state of that thread, so "orig_eax"(ia32), "orig_rax"(x86_64) or
>> "gpr0"(ppc) does not contain the value of system call number any more.
>>
>> [...]
>>
>> The only thing I could figure out to fix this problem is to add a
>> SyscallObserver to update system call number cached in
>> SyscallEventInfo, or some where else, when enter in a system call, and
>> return system call numbers to other objects that want to know system
>> call information. (Any other solutions, free to tell me)
>>     
>
> SyscallObservers are all "equal", you cannot currently add one that has
> preference over any of the others. But the Task or TaskState could hold
> this info if needed.
>
> What is precisely the use case? When does a SyscallObserver want to get
> at the syscall number (or arguments) on exit? Can we assume that a
> SyscallObserver will record Enter/Exit pairs themselves? If so then a
> SyscallObserver should probably have saved the syscall number and any
> arguments it is interested in on updateSyscallEnter() so it can use them
> in updateSyscallExit(). Then when updateSyscallExit() is called the only
> "valid" thing to query is the return value.
>
>   
Yes.  If there's one system call that modifies the syscall num, then I'm 
sure there'll be others.
I'd for the moment just have the client cache the number locally.   When 
there proves to be sufficient demand, having the core cache that value 
becomes an option.

Andrew

Re: System call number cached with help from SyscallObserver

[Andrew Cagney]

Mark Wielaard wrote:
> Hi Andrew,
>
> On Fri, 2006-09-15 at 11:16 -0400, Andrew Cagney wrote:
>   
>> The sole purpose of of Action is to provide a mechanism that facilitates 
>> the implementation of both in-band and out-of-band handling of 
>> notifications.
>>     
>
> What does that mean?
>
>   
in-band == handle within the core's event-loop thread - don't block
this obviously implies that during processing the core event-loop is 
stalled; while simple, it is also an architectural compromise

out-of-band == handle by some other thread - block then unblock
since the event-loop is never stalled more parallelism is possible

Andrew

Re: System call number cached with help from SyscallObserver

[Tom Tromey]

>>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:

Mark> What is precisely the use case? When does a SyscallObserver want to get
Mark> at the syscall number (or arguments) on exit?

Here's one example:

http://sourceware.org/bugzilla/show_bug.cgi?id=3185

Mark> Can we assume that a
Mark> SyscallObserver will record Enter/Exit pairs themselves? If so then a
Mark> SyscallObserver should probably have saved the syscall number and any
Mark> arguments it is interested in on updateSyscallEnter() so it can use them
Mark> in updateSyscallExit(). Then when updateSyscallExit() is called the only
Mark> "valid" thing to query is the return value.

Speaking as a user of this API... I'm definitely surprised to find out
that this wouldn't work on syscall exit.  Of course, this isn't so bad
if the restrictions are documented, and preferably enforced in the
implementation.  E.g., it wouldn't be too bad to have to call
cacheArgumentData() and then have getArguments() fail if the syscall
exited and this was not called.  (BTW, getArguments is wrongly named
afaics, since it actually fetches a single argument...)

Having the user store the data by hand is certainly possible.
However, there are a few ugly bits.  For instance, currently there's
no public info about the number and types of syscall arguments.

Also in my hacked ftrace I was able to get the appended exception.
From what I can tell I can't even fetch the Syscall object in the
updateSyscallExit callback.

I got this by tracing bash and running 'ls'; when ls exits I get the
exception.

Also once I get this exception the traced process seems to be in a
weird state... I tried tracing this bash again, and the bash becomes
non-responsive (as if the ptrace attach succeeded), but the new ftrace
instance prints nothing.  To see this I think you'd need my ftrace
with '-p' support.

Tom

29084.29084 <SYSCALL> sigreturn ()Exception in thread "Thread-1" java.lang.RuntimeException: Negative syscall number: -1
   at frysk.proc.Syscall.syscallByNum(Syscall.java:268)
   at frysk.proc.LinuxIa32Syscall.syscallByNum(LinuxIa32Syscall.java:507)
   at frysk.proc.LinuxIa32$1.getSyscall(LinuxIa32.java:66)
   at frysk.ftrace.Ftrace$SyscallObserver.updateSyscallExit(Ftrace.java:357)
   at frysk.proc.Task.notifySyscallExit(Task.java:834)
   at frysk.proc.TaskState$Running.handleSyscalledEvent(TaskState.java:1083)
   at frysk.proc.Task.processSyscalledEvent(Task.java:412)
   at frysk.proc.LinuxHost$PollWaitOnSigChld$2.syscallEvent(LinuxHost.java:376)
   at frysk.sys.Wait.waitAllNoHang(Wait.cxx:230)
   at frysk.proc.LinuxHost$PollWaitOnSigChld.execute(LinuxHost.java:419)
   at frysk.event.EventLoop.runEventLoop(EventLoop.java:309)
   at frysk.event.EventLoop.run(EventLoop.java:415)

Re: System call number cached with help from SyscallObserver

[Yao Qi]

On Fri, Sep 15, 2006 at 01:47:57PM +0200, Mark Wielaard wrote:
> Hi Yao,
> 
> On Fri, 2006-09-15 at 15:05 +0800, Yao Qi wrote:
> > It is not *always* right to get system call number from a certain
> > register when exit from a system call, such as rt_sigreturn.  This
> > problem has been discussed in this thread,
> > 
> > http://sources.redhat.com/ml/frysk/2006-q3/msg00305.html
> > 
> > Andrew explained that *all* the registers have been flushed to restore
> > the state of that thread, so "orig_eax"(ia32), "orig_rax"(x86_64) or
> > "gpr0"(ppc) does not contain the value of system call number any more.
> > 
> > [...]
> >
> > The only thing I could figure out to fix this problem is to add a
> > SyscallObserver to update system call number cached in
> > SyscallEventInfo, or some where else, when enter in a system call, and
> > return system call numbers to other objects that want to know system
> > call information. (Any other solutions, free to tell me)
> 
> What is precisely the use case? When does a SyscallObserver want to get
> at the syscall number (or arguments) on exit? Can we assume that a
Here is an example,

  class SyscallObserver implements TaskObserver.Syscall
  {
  ......
  public Action updateSyscallExit(Task task)
    {
      SyscallEventInfo syscallEventInfo = getSyscallEventInfo(task);
      int syscallNum = syscallEventInfo.number (task);
      if (syscallNum == SyscallNum.SYSopen
          || syscallNum == SyscallNum.SYSclose)
        {
          exited++;
        }
      return Action.CONTINUE;
    }
  ......
  }

System call number is needed in updateSyscall{Enter|Exit}.

The problem is that system call number is needed in
updateSyscall{Enter|Exit}, but the method to get system call number,
when enter and exit syscall, should be different.(get number from a
register when enter, and get number from a cached value when exit),
but SyscallEventInfo.number does not know it is called in 
updateSyscallEnter or updateSyscallExit.

> SyscallObserver will record Enter/Exit pairs themselves? If so then a
> SyscallObserver should probably have saved the syscall number and any
> arguments it is interested in on updateSyscallEnter() so it can use them
> in updateSyscallExit(). Then when updateSyscallExit() is called the only
> "valid" thing to query is the return value.

There are two methods for interface TaskObserver.Syscall,
updateSyscallEnter and updateSyscallExit, and they are invoked when
enter and exit a system call.

Yes, SyscallObserver *should* have saved the syscall number in
updateSyscallEnter(), but updateSyscallEnter() does not save syscall
number now.

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)

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.

-- 
Yao Qi

Re: System call number cached with help from SyscallObserver

[Phil Muldoon]

> 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

Re: System call number cached with help from SyscallObserver

[Yao Qi]

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

On Tue, Sep 19, 2006 at 04:44:10PM -0500, Phil Muldoon wrote:

Here is my patch to cache system call number.

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

2006-09-20  Yao Qi  <qiyaoltc@cn.ibm.com>
 
        * SyscallEventInfo.java (getSyscall): New abstract method.
        (number): New method.
     
        * LinuxEMT64.java (getSyscall): Implement this method.
        * LinuxIa32.java: Likewise.
        * LinuxPPC.java: Likewise.
        * LinuxPPC64.java: Likewise.
     
        * TestTaskSyscallObserver.java: Test system call number could
        be cached or not. 

Test this patch on x86/x86_64/ppc64, and this patch could also fix bug
#3010.
 
-- 
Yao Qi

[-- Attachment #2: SyscallCache.patch --]
[-- Type: text/plain, Size: 6663 bytes --]

Index: frysk-core/frysk/proc/LinuxEMT64.java
===================================================================
RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxEMT64.java,v
retrieving revision 1.4
diff -u -r1.4 LinuxEMT64.java
--- frysk-core/frysk/proc/LinuxEMT64.java	19 Sep 2006 01:21:22 -0000	1.4
+++ frysk-core/frysk/proc/LinuxEMT64.java	20 Sep 2006 00:42:34 -0000
@@ -72,6 +72,11 @@
 	  int number = this.number(task);
 	  return LinuxX8664Syscall.syscallByNum (task, number);
 	}
+	public Syscall getSyscall(Task task, boolean enterSyscall)
+	{
+	  int number = super.number(task, enterSyscall);
+	  return LinuxX8664Syscall.syscallByNum (task, number);
+	}
       };
     return info;
   }
Index: frysk-core/frysk/proc/LinuxIa32.java
===================================================================
RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxIa32.java,v
retrieving revision 1.9
diff -u -r1.9 LinuxIa32.java
--- frysk-core/frysk/proc/LinuxIa32.java	14 Sep 2006 05:58:58 -0000	1.9
+++ frysk-core/frysk/proc/LinuxIa32.java	20 Sep 2006 00:42:34 -0000
@@ -65,6 +65,11 @@
 	  int number = this.number(task);
 	  return LinuxIa32Syscall.syscallByNum (task, number);
 	}
+	public Syscall getSyscall (Task task, boolean enterSyscall)
+	{
+	  int number = super.number(task, enterSyscall);
+	  return LinuxIa32Syscall.syscallByNum (task, number);
+	}
 	};
     return info;
   }
Index: frysk-core/frysk/proc/LinuxPPC.java
===================================================================
RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxPPC.java,v
retrieving revision 1.6
diff -u -r1.6 LinuxPPC.java
--- frysk-core/frysk/proc/LinuxPPC.java	19 Sep 2006 01:21:22 -0000	1.6
+++ frysk-core/frysk/proc/LinuxPPC.java	20 Sep 2006 00:42:34 -0000
@@ -41,6 +41,11 @@
 	  int number = this.number(task);
 	  return LinuxPowerPCSyscall.syscallByNum (task, number);
 	}
+	public Syscall getSyscall(Task task, boolean enterSyscall)
+	{
+	  int number = super.number(task, enterSyscall);
+	  return LinuxPowerPCSyscall.syscallByNum (task, number);
+	}
         };
     return info;
   }
Index: frysk-core/frysk/proc/LinuxPPC64.java
===================================================================
RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxPPC64.java,v
retrieving revision 1.6
diff -u -r1.6 LinuxPPC64.java
--- frysk-core/frysk/proc/LinuxPPC64.java	19 Sep 2006 01:21:22 -0000	1.6
+++ frysk-core/frysk/proc/LinuxPPC64.java	20 Sep 2006 00:42:34 -0000
@@ -40,7 +40,11 @@
 	  int number = this.number(task);
 	  return LinuxPowerPCSyscall.syscallByNum (task, number);
 	}
-
+	public Syscall getSyscall(Task task, boolean enterSyscall)
+	{
+	  int number = super.number(task, enterSyscall);
+	  return LinuxPowerPCSyscall.syscallByNum (task, number);
+	}
 	};
     return info;
   }
Index: frysk-core/frysk/proc/SyscallEventInfo.java
===================================================================
RCS file: /cvs/frysk/frysk-core/frysk/proc/SyscallEventInfo.java,v
retrieving revision 1.5
diff -u -r1.5 SyscallEventInfo.java
--- frysk-core/frysk/proc/SyscallEventInfo.java	14 Sep 2006 05:58:58 -0000	1.5
+++ frysk-core/frysk/proc/SyscallEventInfo.java	20 Sep 2006 00:42:34 -0000
@@ -48,7 +48,31 @@
   public final static int EXIT = 1;
   public final static int UNKNOWN = -1;
   
+  int syscallNumber = -1;
+
+  /**
+   * Get the system call number from a certain register
+   * @param task the task that system call occurred
+   * @return system call number
+   */
   public abstract int number (Task task);
+
+  /**
+   * When enter into a system call, get system call number from a
+   * certain register and cache it, while exit from system call,
+   * get the system call number from the cached value.
+   * @param task the task that system call occurred
+   * @param enterSyscall get system call number on the moment that 
+   * enter or exit a system call
+   * @return system call number
+   */
+  public int number (Task task, boolean enterSyscall)
+  {
+    if (enterSyscall)
+      syscallNumber = number (task);
+
+    return syscallNumber;
+  }
   /** 
    * getSyscall does everything on the assumption that there is a 
    * system, and programmer want to know the information about this
@@ -58,6 +82,13 @@
    * @return the Syscall object
    */
   public abstract Syscall getSyscall (Task task);
+  /**
+   * @param task the task that system call occurred
+   * @param enterSyscall enterSyscall get system call number on the moment that 
+   * enter or exit a system call
+   * @return the Syscall object
+   */
+  public abstract Syscall getSyscall (Task task, boolean enterSyscall);
 
   /** 
    * @param task the task that system call occurred
Index: frysk-core/frysk/proc/TestTaskSyscallObserver.java
===================================================================
RCS file: /cvs/frysk/frysk-core/frysk/proc/TestTaskSyscallObserver.java,v
retrieving revision 1.16
diff -u -r1.16 TestTaskSyscallObserver.java
--- frysk-core/frysk/proc/TestTaskSyscallObserver.java	7 Aug 2006 20:22:15 -0000	1.16
+++ frysk-core/frysk/proc/TestTaskSyscallObserver.java	20 Sep 2006 00:42:35 -0000
@@ -480,31 +480,33 @@
 	    public Action updateSyscallEnter (Task task)
 	    {
 		super.updateSyscallEnter (task);
-		SyscallEventInfo syscallEventInfo = getSyscallEventInfo(task);
-		int syscallNum = syscallEventInfo.number (task);
+		frysk.proc.Syscall syscall = getSyscallEventInfo(task).getSyscall(task, true);
+
 		// verify that read attempted
-		if (syscallNum == SyscallNum.SYSread) { 
-		    long numberOfBytes = syscallEventInfo.arg (task, 3);
+		if ("read".equals(syscall.getName())) 
+		  { 
+		    long numberOfBytes = syscall.getArguments (task, 3);
 		    logger.log(Level.FINE, "{0} updateSyscallEnter READ\n", this);
 		    if (numberOfBytes != 1)
 			throw new RuntimeException ("bytes to read not 1");
 		    if (readEnter == 0)
 			Manager.eventLoop.add (new PausedReadTimerEvent (task, 500));
 		    ++readEnter;
-		}
+		  }
 		return Action.CONTINUE;
 	    }
 	    public Action updateSyscallExit (Task task)
 	    {
 		super.updateSyscallExit (task);
-		SyscallEventInfo syscallEventInfo = getSyscallEventInfo(task);
-		int syscallNum = syscallEventInfo.number (task);
-		if (syscallNum == SyscallNum.SYSread) {
+		frysk.proc.Syscall syscall = getSyscallEventInfo(task).getSyscall(task, false);
+
+		if ("read".equals(syscall.getName())) 
+		  {
 		    logger.log(Level.FINE, "{0} updateSyscallExit READ\n", this);
 		    if (readEnter <= readExit)
 			throw new RuntimeException ("Read exit before enter");
 		    ++readExit;
-		}
+		  }
 		return Action.CONTINUE;
 	    }
             public Action updateSignaled (Task task, int sig)

Re: System call number cached with help from SyscallObserver

[Phil Muldoon]

Yao Qi wrote:
> On Tue, Sep 19, 2006 at 04:44:10PM -0500, Phil Muldoon wrote:
>
> Here is my patch to cache system call number.
>
> In this patch, 
> 1) add a new member syscallNumber in SyscallEventInfo to
> cache the system call number.
> 2) add a new method getSyscall(Task task, boolean enterSyscall) to
> differentiate it is called by updateSyscallEnter or updateSyscallExit.
>   
+1.

The patch looks good to me

Regards

Phil

Re: System call number cached with help from SyscallObserver

[Tom Tromey]

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

Re: System call number cached with help from SyscallObserver

[Yao Qi]

On Wed, Sep 20, 2006 at 02:02:40PM -0600, Tom Tromey wrote:
> >>>>> "Yao" == Yao Qi <qiyaoltc@cn.ibm.com> writes:
> 
> 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?
I prefer the latter one.

I still have two questions in my mind,

1) Shall we create two objects of SyscallEventInfo, or extend two new
classes from SyscallEventInfo?

2) Supposing there are two objects, one is about enter a syscall and
another is about exit a syscall.  Does object about enter syscall
cache the system call number? (I think yes)  If object about enter a
syscall cache the syscall number, how could it pass this system call
number to the object about exit a system call?

-- 
Yao Qi

Re: System call number cached with help from SyscallObserver

[Tom Tromey]

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

Yao> 1) Shall we create two objects of SyscallEventInfo, or extend two new
Yao> classes from SyscallEventInfo?

Good question.

Yao> 2) Supposing there are two objects, one is about enter a syscall and
Yao> another is about exit a syscall.  Does object about enter syscall
Yao> cache the system call number? (I think yes)  If object about enter a
Yao> syscall cache the syscall number, how could it pass this system call
Yao> number to the object about exit a system call?

Another good question.

One idea would be to have two different interfaces, one for entering a
syscall and one for exiting.  Then there would be a single class which
implements both.  This would allow for identity to be well handled,
and would prevent users from directly calling methods which were
unavailable.

This seems a little clunky though.  Perhaps some other solution is
available.

One thing to consider is that if an observer has to track the
relationship between the enter and exit event objects, then there
needs to be some relatively simple way to track syscalls which do not
have an exit event (e.g., a successful exec) -- otherwise bookkeeping
on the observer side could be difficult or impossible.


Another way to go is to have one class, with a special "cache the
arguments" request, and have getArgument throw an exception if the
cache request call was not made at syscall enter time.  One way that
this is nice is that if multiple observers need a cache, the lookups
will only be done a single time.


I'm just throwing out ideas here.  I don't have a strong feeling for
what the best approach is.  I just want to avoid situations where
writing observers is overly hard or expensive, or situations where
"obvious" uses of the API randomly fail, as is now the case.

Tom

Cache system call number in Task

[Yao Qi]

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

Here is another scheme on system call cache in Task.

In the current implementation, Task.getSyscallEventInfo() return a
SyscallEventInfo object to access syscall number and Syscall object,
so that all the clients(test cases, or ui) could access the real
register to get the system call number, which may cause the negative
syscall number problem.  Why don't we provide a SyscallEventInfo
object that could *only* access cached syscall number in Task, instead
of fetch syscall number from a register?  At the same time, Task could
maintain and update the cached syscall number for itself.

Task gets an "internal" SyscallEventInfo from Linux<ISA> to access
register to get the information about system call, while Task provides
an "external"  SyscallEventInfo for all clients(test cases, ui or
other components want to know system call information), which could
*only* access cached system call number in Task.


2006-10-24  Yao Qi  <qiyaoltc@cn.ibm.com>

        * Task.java (getSyscallEventInfo): Return syscallEventInfo
        that could only access cached system call number.
        (notifySyscallEnter): Update the cached system call number.


The advantage of this scheme is minimized changes on interface, and more
reasonable than my previous patches, at least for me.

Test it on x86/x86_64/ppc64, please review!  Any comments?  Thanks!

-- 
Yao Qi

[-- Attachment #2: CacheSyscallNumTask.patch --]
[-- Type: text/plain, Size: 1996 bytes --]

Index: frysk-core/frysk/proc/Task.java
===================================================================
RCS file: /cvs/frysk/frysk-core/frysk/proc/Task.java,v
retrieving revision 1.105
diff -u -r1.105 Task.java
--- frysk-core/frysk/proc/Task.java	18 Oct 2006 18:14:28 -0000	1.105
+++ frysk-core/frysk/proc/Task.java	24 Oct 2006 01:04:45 -0000
@@ -63,6 +63,9 @@
 
   private Dwfl dwfl;
 
+  private SyscallEventInfo syscallEventInfo = null;
+  private int SyscallNum = -1;
+  
   /**
    * Return the task's corresponding TaskId.
    */
@@ -104,7 +107,19 @@
   public final SyscallEventInfo getSyscallEventInfo ()
     throws TaskException
   {
-    return ((SyscallEventDecoder)getIsa()).getSyscallEventInfo();
+    if (syscallEventInfo == null)
+      syscallEventInfo = new SyscallEventInfo ()
+      {
+        public int number (Task task)
+	{
+          return SyscallNum;
+	}
+        public Syscall getSyscall(Task task)
+        {
+	  return Syscall.syscallByNum(SyscallNum, task);
+        }
+	};
+    return syscallEventInfo;
   }
 
   public final DwflLine getDwflLineXXX ()
@@ -782,19 +797,22 @@
   {
     try 
       {
-	logger.log(
-		   Level.FINE,
-		   "{0} notifySyscallEnter {1}\n",
-		   new Object[] 
-		     { this,
-		       new Integer(this.getSyscallEventInfo().number(this))
-		     });
+        // Cache the system call number.
+        this.SyscallNum = ((SyscallEventDecoder)getIsa()).getSyscallEventInfo().number(this);
       }
     catch (TaskException e) 
       {
 	logger.log(Level.SEVERE, "TaskException in {0}", this);
 	throw new RuntimeException("caught TaskException", e);
       }
+    logger.log(
+               Level.FINE,
+               "{0} notifySyscallEnter {1}\n",
+               new Object[] 
+                 { this,
+                   new Integer(this.SyscallNum)
+                 });
+
     for (Iterator i = syscallObservers.iterator(); i.hasNext();)
       {
         TaskObserver.Syscall observer = (TaskObserver.Syscall) i.next();