HN Gopher Feed (2017-09-25) - page 1 of 10 ___________________________________________________________________
Linux System Call Table
120 points by thevivekpandey
http://thevivekpandey.github.io/posts/2017-09-25-linux-system-ca...___________________________________________________________________
eatonphil - 3 hours ago
This is great! It would be even more useful to have this for Mac
OSX too. A lot of the projects I do ends up being on both Mac and
Linux. It's always a pain to find the corresponding number for the
system call on Mac.
legulere - 2 hours ago
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
zzzcpan - 1 hours ago
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.
smhenderson - 39 minutes ago
if you're going to implement that kind of overhead why not
just use libc?
zzzcpan - 12 minutes ago
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.
wahern - 7 minutes ago
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.
throwaway613834 - 2 hours ago
What is the use case for this? Is it for someone trying to write
their own syscall wrappers?
yalue - 2 hours ago
Sometimes, yes, you'll need to write your own syscall wrappers.
For example, there isn't a gettid (get thread ID) function in
Glibc, but you can work around this by calling the syscall
directly.The other case where this is useful is if you're wanting
to write userspace assembly without calling a C library. This may
be especially useful when you're writing a compiler, or if you're
trying to write small shellcodes for some reason.
[deleted]
Manozco - 2 hours ago
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, you don't need anything
else. On the contrary if you want to reimplement a BSD you need
to reimplement their libc (and perhaps some other libraries)
spilk - 35 minutes ago
What about non-x86/64 platforms?
akrasuski1 - 2 hours ago
That's all cool and everything, but the registers are wrong... Not
only are they 32-bit (eax vs. rax), but their order is wrong too -
the first argument in x86-64 ABI is rdi, for example.
khedoros1 - 1 hours ago
The registers look correct for the i386 ABI. eax for the system
call number, then ebx, ecx, edx, esi, edi, ebp for the next 6
arguments.I skimmed a couple files in the code. And it seems like
it might be parsing this information out of some other sources,
and maybe getting confused about the info it's
grabbing?https://github.com/thevivekpandey/syscalls-table-64bit
amluto - 3 hours ago
I'm a bit puzzled. The code is at "syscalls-table-64bit", yet the
regs are eax, etc. This makes very little sense.In any event, I
think the args should just be labeled arg0..arg5.
LukeShu - 3 hours ago
In several cases, the order of the args for a syscall varies
between architectures--writing a general "arg0" doesn't make a
lot of sense.That said, I don't know what's up with it using
32-bit register names.
webreac - 3 hours ago
If 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.
vog - 2 hours ago
If you want that level of quality, don't use Linux, use instead
FreeBSD or OpenBSD.
valarauca1 - 2 hours ago
Michael Kerris keeps and up to date reference [1]. Even details
_all_ system calls [2].[1] https://www.kernel.org/doc/man-
pages/[2] http://man7.org/linux/man-pages/dir_section_2.html
mjw1007 - 2 hours ago
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.
milcron - 2 hours ago
For the BSDs, incorrect or missing man pages are considered a
serious bug.
dom0 - 2 hours ago
Man pages aren't even in the kernel tree.
zokier - 2 hours ago
So the issues noticed so far:* Missing syscalls* Wrong syscall
numbers* Wrong calling convention* Links to source are to wrong
versionDoes the table get actually anything right? I mean this is
pretty spectacular cascade of failures.
Skunkleton - 1 hours ago
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'.
kahlonel - 4 hours ago
This is very handy with the asm registers mapped to arguments.
Thanks!
rhinoceraptor - 1 hours ago
Someone should put together a list of which ones are irredeemably
broken (and as such, humanity is stuck with a broken ABI in
perpetuity), e.g. epoll.
language - 2 hours ago
Ah, this is neat! Would be nice to have a script for this that you
could just point at a local copy of the source tree too!
fbourque - 3 hours ago
Nice work. the table has been generated for 4.10 and hence the link
to the source code files should also have this kernel version in
the path of the url for direct access
sigjuice - 2 hours ago
This man page describes the syscall ABI for all architectures.
http://man7.org/linux/man-pages/man2/syscall.2.html
dmix - 3 hours ago
Nice, I'm curious how it maps the system call to the source code
line number dynamically? (Edit: seems like ctags + http://elixir
.free-electrons.com/linux/latest/source [1]) It supports every
kernel version.The linked source code browser seems like a useful
way to check the history of system calls for research...[1]
https://github.com/thevivekpandey/syscalls-table-64bit/blob/...
akrasuski1 - 2 hours ago
Actually, 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.
scott_s - 2 hours ago
I think you're right - the submitted table has no entries for
"fork" and "clone".