21–30 of 65 posts
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.
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.
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.
* 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.
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.
So 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.
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.
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?
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.
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.
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
Earlier 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.