This is the mail archive of the
mailing list for the frysk project.
[rfc] Remove SyscallNum.shjava and maintain syscallList manually for different architectures
- From: Yao Qi <qiyaoltc at cn dot ibm dot com>
- To: frysk <frysk at sourceware dot org>
- Cc: Mark Wielaard <mark at klomp dot org>
- Date: Mon, 4 Sep 2006 19:46:41 +0800
- Subject: [rfc] Remove SyscallNum.shjava and maintain syscallList manually for different architectures
It is very convenient to generate SyscallNum.java by SyscallNum.shjava
in a automatic way, but there are some shortcomings for this script
Mark, add you in CC list for d).
a) SyscallNum.shjava miss some syscalls.
I posted this problem here,
regular expression in SyscallNum.shjava could not cover all syscall
Actually, this point is not strong enough to remove this script, but
the following ones are persuasive, IMO.
b) SyscallNum.shjava is for "host", instead of for "target".
The scheme in SyscallNum.shjava is to extract syscall num from the
output of GCC extension on "host". Mostly, syscall num is different
when "target" != "host". For example, when a i386 program running on
a X86_64 machine, SyscallNum.SYSread should be the number of SYSCALL
read on i386, instead of X86_64.(SyscallNum.SYSread on X86_64 is 0)
c) syscallList in Syscall.java is hardwired to Linux+i386.
If we could extend syscallList for other platforms(of course, we
should), syscallList could replace SyscallNum.java produced by
d) Some "sub-syscalls", such as connect() and listen(), could not be
listed by SyscallNum.shjava.
Mark present this problem here,
We could add "bind", "listen", to syscallList with the same syscall
number, and Syscall.java provides some methods, such as
isSyscall(String), for Syscall Observers, like this,
public Action updateSyscallEnter (Task task)
syscall = Syscall.getSyscall (int syscallNum); // A Factory maybe.
// Yao is not sure he could get first syscall argument in Syscall.
Any comments are welcome. Thanks!