What about non-x86/64 platforms?
Linux System Call Table
31–40 of 65 posts
Re: Linux System Call Table
#32Earlier quoted context omitted.
Linux doesn't guarantee syscall stability either. Just make sure your wrappers can use a syscall table chosen at runtime, depending on which kernel you are running.
if you're going to implement that kind of overhead why not just use libc?
I'm not sure what you mean by overhead. It's not that hard or expensive to choose a few function pointers on program start.
Re: Linux System Call Table
#33Earlier quoted context omitted.
System calls have not stability guarantee on macOS. You should use libc instead. In general the use of syscalls directly is fairly limited. Edit: for instance go broke once for macOS Sierra, when Apple changed the gettimeofday system call: https://github.com/golang/go/issues/16570
Linux doesn't guarantee syscall stability either. Just make sure your wrappers can use a syscall table chosen at runtime, depending on which kernel you are running.
Yes it does, at least in the sense that syscalls which become officially public will never be removed from Linus' tree except in rare circumstances (i.e. proof that nobody is using it), nor will the arguments change. This is Linus' famous "never break user space" ABI mantra. While distributions may deprecate and remove them (e.g. sysctl(2)) they certainly won't be assigned new IDs. A table won't help in such cases.
Re: Linux System Call Table
#34So the issues noticed so far: * Missing syscalls * Wrong syscall numbers * Wrong calling convention * Links to source are to wrong version Does the table get actually anything right? I mean this is pretty spectacular cascade of failures.
At least for x86, you can get this same information fairly easily directly from the source. The table is located at arch/x86/entry/syscalls/syscall_64.tbl, from there you can grep for the function with git grep. For example, git grep 'SYSCALL_DEFINE.*read'.
why bother with git grep vs. just vanilla grep. i could see the use if you're working with an older binary, but you didn't mention.
Re: Linux System Call Table
#35I put out a syscall table back in the day for Linux 2.2 (up to %eax 190). Someone copied it (I'm glad.): https://www.cs.utexas.edu/~bismith/test/syscalls/syscalls32.... They didn't attribute it to me, but I remember a professor did for his class. There were better tables after that I admit, though I liked my version because it linked into the source code.
Re: Linux System Call Table
#36What is the use case for this? Is it for someone trying to write their own syscall wrappers?
You might need that when you want to reimplement Linux, the Joyent team did that on their OS (derived from solaris) so that user can run linux binaries on a solaris kernel (so thay have dtrace, zfs, mdb, ...) Bryan Cantrill did a bunch of conferences on that (one here: https://youtu.be/TrfD3pC0VSs ) The idea behind is that Linux is only a list of syscalls, if you are able to reimplement them, you reimplement linux, y…
For that matter, this is how Widows's Linux compatibility layer works.
Re: Linux System Call Table
#37Earlier quoted context omitted.
At least for x86, you can get this same information fairly easily directly from the source. The table is located at arch/x86/entry/syscalls/syscall_64.tbl, from there you can grep for the function with git grep. For example, git grep 'SYSCALL_DEFINE.*read'.
why bother with git grep vs. just vanilla grep. i could see the use if you're working with an older binary, but you didn't mention.
If you ran something like grep -r SYSCALL_DEFINE.read from the top level of the linux source it would search through not just your source code, but also all of the artifacts of building the kernel. Basically, git grep is faster in this case because it filters the searched files down to only ones that are checked in. You could achieve a similar effect with standard tools like this: find -type f -regex '.\.[hc]' | xargs grep 'SYSCALL_DEFINE.*read'
Re: Linux System Call Table
#38Actually, the syscall numbers are wrong! This reference seems better: http://blog.rchapman.org/posts/Linux_System_Call_Table_for_x... Consider simple C program: #define _GNU_SOURCE #include int main(){ syscall(276); } Strace'ing it shows the syscall used is tee, just as the reference I linked shows, and not pwritev as in OP's table.
strace is not a proof. It has it's own built-in table. So also strace could be wrong.
In practice strace is widely used and bugs should be discovered, reported, and fixed soon. So without doing any own analysis I'd bet that in doubt this table is wrong and strace right.
Note that syscall list and numbers are architecture specific. The differences are typically not huge, but they exist.
Re: Linux System Call Table
#39If man pages were up to date, this should be the index of chapter 2. I have discover unix with sun in the 90s and I am very nostalgic of the quality of man pages. At that time, man pages were complete and up to date. My latest frustration was with the option -m of df command. Chapter 2 should be updated each time a new version of kernel is installed.
It's very strange that adding/updating documentation isn't treated as a basic requirement for a patch that adds to or modifies Linux's public interfaces.
From Documentation/process/submit-checklist.rst:
19) All new userspace interfaces are documented in ``Documentation/ABI/``.
See ``Documentation/ABI/README`` for more information.
Patches that change userspace interfaces should be CCed to
linux-api@vger.kernel.org.Re: Linux System Call Table
#40This man page describes the syscall ABI for all architectures. http://man7.org/linux/man-pages/man2/syscall.2.html
...and the syscalls(2) man page lists them: http://man7.org/linux/man-pages/man2/syscalls.2.html