Re: About system call handling in Frysk

[Wu Zhou <woodzltc at cn dot ibm dot com>]

Andrew,

Sorry for replying later. I experienced some problems with my machine 
and mailbox recently.  :-(

On Wed, 29 Mar 2006, Andrew Cagney wrote:

[snip]
> > 1. to print system calls as intuitively and descriptively as possible
> > 
> >   
> I think this is actually a secondary goal (or perhaps can be thought of as a
> bonus from good design).  That the current code made this the sole focus is
> unfortunate.  If all someone wants to do is generate system traces then they
> can and will use strace.

For the user's sake, I think it is a desirable goal. But I accept that it 
can be treated as a secondary goal.  :)

> As your go on to explain there are a number of components:
> 
> - the ISA/ABI specific calling convention object.
> Given a thread, and the knowledge of a specific ISA/ABI, this knows how to
> extract raw system call entry and exit values.  At present this is implemented
> as SyscallEventInfo; SyscallEventInfo .number (Task), for instance, returns
> the system call number extracted from the task.  As you explain,
> implementations for more ISA's and architectures are required.

Do you have any idea on how to get the knowledge of the specific ISA/ABI 
from the underlying thread?  I guess that we need the kernel's support.

Based on LinuxIa32.java, I had a draft implementation for PPC32 and PPC64 
(named LinuxPpc32.java, LinuxPpc64.java).  Although very coarse and a little 
trick is needed, they worked for me.  I can extract the syscall number and 
return value.  A problem concerns me is that the ptrace interface is not 
that compatible on different architecture (one example is that ptrace on 
ppc64 need aligned to 8-byte boundary).  Maybe we can suggest the kernel 
to fix this?  

> - the per-kernel system call database (you called it SyscallNum)
> At present this is hardwired in Syscall.java; and is customized for printing
> system call information to stdout.  I think the object should be better
> abstracted so that it describes the system call - name, number, return,
> arguments and that means doing better than single letters as the encoding.  It
> would also need to encapsulate the possibility of multiple system call numbers
> for single name.  Being able to generate this from kernel information would be
> ideal (other kernels actually contain such a file and generate the system call
> code using that as input).  What of the possibility of loading the file at
> run-time, rather than generating / wiring it in?

Yes.  I see it is hard-wired.  One option I thought of is to manually maintain
these information.  Although I accept that it is not that better than generating
at run-time from the underlying kernel, it is a feasible alternative, 
provided that it is not easy for kernel to adopt this idea (even if they 
accept the idea, I believe that it won't be a short time for this come 
into the official kernel).

In /proc fs, there is a file named kallsyms, there are some information 
about the system call.  But that is not enough for us.  Maybe we need the 
underlying kernel to export these information for us.  I guess this is a 
reasonable request for kernel guys, provided that they are the API kernel 
served the user-space.  I even thought out of a name for these kinds of 
information: /proc/kapi/syscalls, /proc/kapi/wordsize, /proc/kapi/endian
and so on....

OK. These are only my personal view.  Maybe you have better idea.  I guess 
you need to convince the kernel guys to buy them.  Maybe this is the 
reason why you prefer to attend OLS other than GCC summit?  :-)

> - a system call print observer
> Given a task, it monitors for system calls, uses the the above two in
> combination to print the system to a stream

I see you have two methods in LinuxIa32.java for this purpose: printCall 
and printReturnCode.  But I just can't make it to print all the system 
calls in the process.  Maybe I need to know Java more, or that the 
printWriter have some kind of length limitation (will ask for your help 
later).
 
> - other more custom observers
> For instance, an observer, might monitor system calls watching for mmap, and
> then when it sees the call take applicable action - such as kill the task.

>From my reading the code, I guess current Frysk already coded in this kind 
of support, right?

> > - The system calls interface in Linux is quite stable, but there
> > are a few changes occasionally.  some old system calls are deprecated,
> > becoming "SYS_NI_SYSCALL"; a few new system call are
> > added as new requirement appears.  Is frysk supposed to support
> > these old system call in old binary?  And is it also supposed to support
> > these new ones just coming into the new kernel?  I believe
> > it will be a good feature if we can support the old deprecated
> > system calls and also the latest added ones.
> > 
> >   
> yes, it is a good goal.  We're after flexibility and maintainability here.  Of
> course, the second iteration (we've already had the first :-) need only focus
> on current kernels.   I've my doubts that any one will run frysk on an old
> kernel :-)

Yes.  I buy this.  :)

> > - Same system call in different architectures might have different
> > number, but they should have the same format information, i.e. argument
> > number, argument types and return type. 
> > (Is the latter assumption make sense?  I didn't notice any negative proof.
> > I would be very surprised if someone can prove me wrong. :-)
> > 
> >   
> I believe so.  I think we can work with that assumption at the moment - lets
> only try to worry about esoteric architectures when we've got esoteric
> architectures to worry about.

Yes.  Quite reasonable.

> > - Some architecture are using multiplexer for some kinds of system
> > call.  For example, x86 and ppc64 are using ipc for ipc related system calls
> > (shmget, shmdt, shmat.....), and using socketcall for
> > socket related system calls (socket, connect, bind, listen...);
> > Other architectures don't. For example, x86_64 don't work in that
> > way, it has different call number for different ipc and socket
> > related system call.
> > 
> >   
> I'm not sure what you mean here.  Based on your other e-mail I know you mean
> more than having a single system call instruction with the call-number stored
> in a register.

Sorry for the confusion.  It is just what you mean.

> > I will post another mail later to discuss a potential solution
> > I am thinking of.
> > 
> > Thanks.
> >   
> I'll look at that next.

It seems that I need to re-think about the solution.  Talk about that 
later.

Thanx
- Wu Zhou