On Tue, Mar 4, 2014 at 11:27 AM, H. Peter Anvin <h...@zytor.com> wrote: > On 02/27/2014 12:40 PM, Andy Lutomirski wrote: >> Currently, dealing with Linux syscalls in an architecture-independent >> way is a mess. Here are some issues: >> >> 1. There's no clean way to map between syscall names and numbers on >> different architectures. The kernel contains a number of tables (that >> work differently for different architectures). strace has some arcane >> mechanism. libseccomp has another. >> >> 2. There's no clean way to map between syscall argument registers and >> logical syscall arguments. Each architecture knows how to do it, as >> do strace and glibc, but I suspect that *everyone* else gets it wrong. >> Especially on ARM. >> >> 3. Determining which architectures have which syscalls is a mess. >> Recent kernel builds love to warn me that finit_module is missing on >> x86_64. This is simply not true. I have no idea why. >> >> 4. Actually issuing a nontrivial syscall is annoying. syscall(2) can >> do it for the native architecture (only). >> >> 5. Decoding ucontext from SIGSYS is a mess. I have prototype code >> for libseccomp that can do it, but it gets the arguments wrong due to >> ABI issues. See (2). >> >> I'd like to see a master list in the kernel that lists, for every >> syscall, the name, the number for each architecture that implements it >> (using the AUDIT_ARCH semantics, probably), and the signature. The >> build process could parse this table to replace the current per-arch >> mess. >> > > Hi Andy, > > I have brought that up a lot of times, originally dating back from my > work on klibc. I have tried to keep the klibc syscall list in a sane > format with architecture annotations, but it doesn't contain all the > syscalls in the system. > > Extending that work and making it encompass everything the kernel > exports would be highly useful, but it would take a lot of work.
I think that SYSCALLS.def won't work as is -- SYSCALLS.def references unistd, which ought to be autogenerated from the syscalls list. But a somewhat less magical variant should work. --Andy ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ libseccomp-discuss mailing list libseccomp-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss
