Please do not use previous workaround in prod, it is bad, just proof of concept.
It looks like nobody is maintaining syscall list. It is not possible to trust it.
We have "arch/mips/kernel/syscalls/syscall_o32.tbl", we need to create generator. Generator should provide maximum possible number of arguments for syscall. For example:
"sys_sync_file_range" has 4 arguments, "sys32_sync_file_range" - 7 arguments. Maximum value - 7 should be stored inside our table.
The problem is that some syscalls in kernel code is prefixed by SYSCALL_DEFINE{N} or COMPAT_SYSCALL_DEFINE{N}. but some (like "sys_sync_file_range" and "sys32_sync_file_range") are not prefixed.
So I think we may have a generator that provides "WAT?" if it don't know the arguments count and require to update value manualy.
Please do not use previous workaround in prod, it is bad, just proof of concept.
It looks like nobody is maintaining syscall list. It is not possible to trust it.
We have "arch/mips/ kernel/ syscalls/ syscall_ o32.tbl" , we need to create generator. Generator should provide maximum possible number of arguments for syscall. For example:
> sync_file_range sys_sync_file_range sys32_sync_ file_range
"sys_sync_ file_range" has 4 arguments, "sys32_ sync_file_ range" - 7 arguments. Maximum value - 7 should be stored inside our table.
The problem is that some syscalls in kernel code is prefixed by SYSCALL_DEFINE{N} or COMPAT_ SYSCALL_ DEFINE{ N}. but some (like "sys_sync_ file_range" and "sys32_ sync_file_ range") are not prefixed.
So I think we may have a generator that provides "WAT?" if it don't know the arguments count and require to update value manualy.