Re: [rfc] Remove SyscallNum.shjava and maintain syscallList manually for different architectures

[Mark Wielaard <mark at klomp dot org>]

On Wed, 2006-09-06 at 19:44 +0800, Yao Qi wrote:
> On Wed, Sep 06, 2006 at 11:36:12AM +0200, Mark Wielaard wrote:
> > 
> > Do you mean the -e <expr> option? (
> > My version of ftrace has -o <x> being redirect output to <x>.
> Do you mean strace here? :)
> There is no option for frace now.

Right, duh. sorry, confusion everywhere.

> > > In the current setup one plausible approach would be to have multiple
> > > Syscall objects with the same number but different names.  Then,
> > > SyscallEventInfo would have an accessor to return the corresponding
> > > Syscall -- which would be the "decoded" one.  Finally, Syscall would
> > > have an equals() method that would compare both the name and the
> > > number.
> > 
> > Yes, that seems the right approach.
> 
> syscalls with different names but the same number could only be found
> on x86, and I could not find the similar case on other platforms.

Yes. Seems this is just socketcall on x86. Strange.
But I think we should handle these as if they are raw syscalls as on
other architectures.

> Actually, I start to rewrite Syscall.java, SyscallEventInfo.java and
> Linux<ISA>.java.  I am not sure I am on a right way, so any advice is
> appreciated.
> 
> 1) Write a new method getSyscall() in SyscallEventInfo to return a
> Syscall object from a *certain* syscallList.
> 
> 2) Build syscallList in every Linux<ISA>.java.
> syscallList varies from ISA, so I place syscallList from Syscall.java
> to Linux<ISA>.java
> On i386, there are 2 syscall numbers for a group of "subcalls", so I
> set up 3 syscallLists, 
> 
>    a) syscallList for common syscalls(1 syscall num, 1 syscall name), 
>    b) socketSubCallList for socket subcalls group.(indexed by first
> argument)
>    c) ipcSubCallList for ipc subcalls group.(indexed by first argument)
> 
> 3) In SyscallEventInfo.getSyscall(),  get syscall number and first
> argument, and return the Syscall object in one of the three
> syscallLists.

Looks fine to me. The current Syscall list also contains an argument
spec. Will you include something similar? It could be nice for the user
of the Syscall to determine the number of arguments and the type of the
return value.

Cheers,

Mark