3 ms·
Actually, the syscall numbers are wrong! This reference seems better: http://blog.rchapman.org/posts/Linux_System_Call_Table_for_x86_64/ http://blog.rchapman.or
by akrasuski1 9y ago
Actually, the syscall numbers are wrong! This reference seems better: http://blog.rchapman.org/posts/Linux_System_Call_Table_for_x86_64/ http://blog.rchapman.org/posts/Linux_System_Call_Table_for_x...
Consider simple C program:
#define _GNU_SOURCE
#include <unistd.h>
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 9y agoI think you're right - the submitted table has no entries for "fork" and "clone".
- usr1106 9y agostrace 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.
- voltagex_ 9y agoIt's odd. The owner of this Git repo has Issues turned off so I can't post a question/issue, and it appears to have been auto-generated - https://github.com/thevivekpandey/syscalls-table-64bit https://github.com/thevivekpandey/syscalls-table-64bit is a "fork" of https://github.com/paolostivanin/syscalls-table-64bit https://github.com/paolostivanin/syscalls-table-64bit