Re: [patch review] Syscall for multi-arch support

[Yao Qi <qiyaoltc at cn dot ibm dot com>]

On Tue, Sep 12, 2006 at 12:39:41PM +0200, Mark Wielaard wrote:
> Hi,
> 
> On Fri, 2006-09-08 at 20:54 +0800, Yao Qi wrote:
> > Some items are listed here to present what I did,
> > 
> 
> Personally I would place the actual lists on their own class files to
> keep the rest of the class files smaller. But that depends on whether
> you like all code to be together as much as possible, or you want code
> as much as possible in separate files.
It is hard to cover when I put syscallList in Linux<ISA>.java, it is
too long.
I will create new files Linux<ISA>Syscall.java for syscallList and
relative stuff.
> 
> As already mentioned the OS + Isa setup is a little odd at the moment.
> It seems part of the design works around the fact that a Isa isn't a
> SyscallEventDecoder, only OS + Isa is. But there is no way to know which
> Isa instance is a OS + Isa, and which are only an Isa.
> 
> If we aren't going to support other OSes than GNU/Linux soon I would
> propose to collapse the Isa/Os classes together and make Isa implement
> SyscallEventDecoder. Currently we have an extra layer of abstraction
> that we aren't using at all.
I agree.
I did not do this along with multi-arch syscall, and that is what 
we could do in the next step.  When syscallList works well for 
multi-arch, this could be done without too much effort.
> 
> >   However, I do not change the spec in syscallList.
> > It would take me a whole day to look up system call numbers for
> > different architectures. :)
> 
> As soon as the setup is good enough for IA32 we should probably divide
> the task between people and make sure the tables are correct for the
> various primary platforms that people use. I would love to see ftrace
> work on x86_64 and strace and systemtap seem to have the appropriate
> lists already so I can help with that arch.
Thanks!
We have built up a "draft" syscallList for X86_64 and PPC64, but we
are still not sure about some details.  I will submit the patch later,
including these syscallLists, and we could check syscalls for
different architectures in a parallel way.
> 
> > 2. New methods to Syscall.
> > Tom submitted a patch about part of this, and I integrate his patch in
> > my changes.  Add equals() in Syscall.
> > 
> > 3. New methods in SyscallEventInfo.
> > a) getSyscall (Task task) return a Syscall object when a syscall happens.
> 
> Should document what happens when not in a syscall.
> 
getSyscall (Task task) will return a meaningless Syscall object when
no syscall happens.  getSyscall first get the number of this system
call from a certain register, and find Syscall object by this system
call number in syscallList.

getSyscall (Task task) does everything on the assumption that there is
an system call, and programmer want to know the information about this
system call.
> > b) getSyscallList() and getUnknownSyscalls() return the
> > architecture-dependent syscallList and unknown syscall hash map from
> > Linux<ISA>.java
> > c) syscallByNum() and syscallByName() are also from Tom's patch.
> 
> I wonder whether you might want a map from names to syscalls. Depending
> on how much syscallByName() is used. It currently does a linear search
> through the array. This might be premature micro-optimizing though.

syscallByName() is not called frequently, and it *may* be only used in
ftrace.  Currently, syscallByName() is not called anywhere.

> 
> Would it make sense to extend Syscall with a getArguments() that returns
> the number of arguments of the syscall? And maybe a way to access the
> arguments with their correct type? It seems we encode that info in the
> Syscall, but don't actually use it at all. That would be really handy
> for inspecting the actual arguments and return values. But maybe this is
> for later.
I agree.
I refactor Syscall as an abstract class, with abstract methods,
getArguments() and getReturnCode(), and Syscall could be extended in
every Linux<ISA>Syscall.java when setting up the syscallList.  Child
class is created for socket subcalls and ipc subcalls respectively,
and getArguments() is overwritten to do different thing.
> 
> > One syscalLList is for socket "subcall".(indexed by first argument)
> > One syscallList is for ipc "subcall".(indexed by first argument)
> 
> Where are these ipc subcalls documented?
These subcalls are semop, semget, semctl, semtimedop, and so forth.

I get them from the src of strace, and you could also find them in 
linux/syscallent.h and  decode_subcall in syscall.c.

> 
> Are the arguments not just shifted by one? if so then just make an
> explicit SubSyscall class for them which just does
> arg(Task t, int n) { return super.arg(t, n + 1); } 
For ipc subcalls, it is true.  These arguments are shifted by one.
For socket subcalls, it is not.  All the arguments are dereferenced
by %ecx (on X86).
> 
> > 
> > Any comments are welcome!
> > 
> > Here is an output from ftrace on x86,
> > (I input Ctrl-C to kill accept)
> 
> Nice output!
> BTW, it should output the port it is listening on to stdin. Then you can
> connect to that port from some other terminal and see it continue.
How could I *connect* to that port in other terminal?

-- 
Yao Qi