GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
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".