3 ms·

Despite what the comment at the start of that file says, these aren't the right syscall numbers for x86-64 (nor x86-32!) 64 bit: read = 0, write = 1, open = 2

Despite what the comment at the start of that file says, these aren't the right syscall numbers for x86-64 (nor x86-32!) 64 bit: read = 0, write = 1, open = 2 ... 32 bit: restart_syscall = 0, exit = 1, fork = 2 ... It's like they shuffle these around on purpose and don't bother to properly document it anywhere.

matheusmoreira 4y ago
You're right, there seems to be some special mechanisms for x86, x86_64 and x86_32. The asm include for x86 is here: https://github.com/torvalds/linux/blob/master/arch/x86/include/uapi/asm/unistd.h https://github.com/torvalds/linux/blob/master/arch/x86/inclu... It includes either unistd_32.h or unistd_64.h. Those headers don't seem to be in the repository anymore. It seems they are generated from the system call tables as sickall mentioned and exported to user space as C header files. https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_32.tbl https://github.com/torvalds/linux/blob/master/arch/x86/entry... https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_64.tbl https://github.com/torvalds/linux/blob/master/arch/x86/entry... The following commit introduced this auto-generation mechanism: https://github.com/torvalds/linux/commit/303395ac3bf3e2cb488435537d416bc840438fcb https://github.com/torvalds/linux/commit/303395ac3bf3e2cb488... Other architectures just define some macros which modify the behavior of the asm-generic unistd.h header. For example, the arm64 unistd.h defines macros and then just includes it: https://github.com/torvalds/linux/blob/master/arch/arm64/include/uapi/asm/unistd.h https://github.com/torvalds/linux/blob/master/arch/arm64/inc... #define __ARCH_WANT_RENAMEAT #define __ARCH_WANT_NEW_STAT #define __ARCH_WANT_SET_GET_RLIMIT #define __ARCH_WANT_TIME32_SYSCALLS #define __ARCH_WANT_SYS_CLONE3 #define __ARCH_WANT_MEMFD_SECRET #include <asm-generic/unistd.h> I suppose x86 is too old or too different to fit this paradigm.

matheusmoreira 4y ago

You're right, there seems to be some special mechanisms for x86, x86_64 and x86_32. The asm include for x86 is here: https://github.com/torvalds/linux/blob/master/arch/x86/include/uapi/asm/unistd.h https://github.com/torvalds/linux/blob/master/arch/x86/inclu... It includes either unistd_32.h or unistd_64.h. Those headers don't seem to be in the repository anymore. It seems they are generated from the system call tables as sickall mentioned and exported to user space as C header files. https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_32.tbl https://github.com/torvalds/linux/blob/master/arch/x86/entry... https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_64.tbl https://github.com/torvalds/linux/blob/master/arch/x86/entry... The following commit introduced this auto-generation mechanism: https://github.com/torvalds/linux/commit/303395ac3bf3e2cb488435537d416bc840438fcb https://github.com/torvalds/linux/commit/303395ac3bf3e2cb488... Other architectures just define some macros which modify the behavior of the asm-generic unistd.h header. For example, the arm64 unistd.h defines macros and then just includes it: https://github.com/torvalds/linux/blob/master/arch/arm64/include/uapi/asm/unistd.h https://github.com/torvalds/linux/blob/master/arch/arm64/inc... #define __ARCH_WANT_RENAMEAT #define __ARCH_WANT_NEW_STAT #define __ARCH_WANT_SET_GET_RLIMIT #define __ARCH_WANT_TIME32_SYSCALLS #define __ARCH_WANT_SYS_CLONE3 #define __ARCH_WANT_MEMFD_SECRET #include <asm-generic/unistd.h> I suppose x86 is too old or too different to fit this paradigm.