Please refactor linux-user/mips/cpu_loop.c Hello. I am working with qemu on test images. I've added a new syscall (436) to qemu but received ENOSYS from mips application. Please open "linux-user/mips/cpu_loop.c". I've added at the end of "mips_syscall_args" the following: ``` MIPS_SYS(sys_getdents64_x32, 3) ``` But ``` syscall_num = env->active_tc.gpr[2] - 4000; if (syscall_num >= sizeof(mips_syscall_args)) { ret = -TARGET_ENOSYS; ``` returns -TARGET_ENOSYS We can see that "linux-user/mips/cpu_loop.c" differs a lot from "linux-user/arm/cpu_loop.c". Arm has it's own "ARM_NR_BASE" and etc. Can you please refactor mips cpu loop in the same way as arm? Thank you. Added workaround for now 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. I've found a reliable way to generate syscall arguments count table. cd /usr/src/linux make clean make CONFIG_DEBUG_INFO=y CONFIG_DEBUG_INFO_SPLIT=y CONFIG_DEBUG_INFO_DWARF4=y llvm-dwarfdump -debug-info --name ksys_getdents64 --show-children --recurse-depth=1 fs/readdir.dwo 0x00013738: DW_TAG_subprogram DW_AT_name ("ksys_getdents64") ... 0x00013752: DW_TAG_formal_parameter ... 0x00013766: DW_TAG_formal_parameter ... 0x00013779: DW_TAG_formal_parameter ... We can count "DW_TAG_formal_parameter" for syscall and it that's it. Unfortunately we can generate only very short table of syscalls using this method. Most of the syscalls are missing from "dwo" files. =( It is possible to do the following: cd /usr/src/linux make clean make CC=clang ~/workspace/CastXML/build/bin/castxml -nostdinc -isystem /usr/lib/clang/9.0.1/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -include ./include/linux/kconfig.h -D__KERNEL__ arch/x86/entry/syscall_32.c --castxml-output=1 -o /tmp/syscall_32.xml It generates all information including params about 32bit syscalls for current amd64 platform. Unfortunately cross compilation of generic kernel using mips clang toolchain is almost impossible today. It is an idea for future. So today we have to parse "include/linux/syscalls.h", "include/linux/compat.h", "arch/mips/kernel/linux32.c", etc without respect to config and syntax. There is already a pending patch for mips that will handle the syscall in question. Will provide drtails tommorow. Andrew, Please take a look at the patch: http://patchwork.ozlabs.org/patch/1217454/ Once you apply the patch, it should be straightforward to add getdents64_x32() (right after clone3()) for all MIPS ABIs. The thing is, kernel folks recently made some rearrangements of syscall numbers, so that all architectures have in future "similar" syscall numbers, but that required some "holes" in syscall numbers schemes for virtuall all archs, and for MIPS among them. That is why ne array in linux-user/mips/cpu_loop.c has some elements defined just as "0" - they are there just to adjust syscall numbers to be in accordance with the new scheme. Please let us know if you are able to work with such solution or not. Happy New Year! Aleksandar Hello, thank you. I want to introduce another patch with syscalls related generator. Please review it. I think about the following development flow: 1. Kernel updates and maintains "tbl". 2. Qemu developer wants to implement new syscall (like clone3) in "linux-user/syscall.c". 3. Developer clones new kernel into some directory and runs generators. 4. All syscall related stuff will be updated immediately. I think it will very straightforward solution. Qemu won't hardcode kernel related stuff and all linkage between kernel and qemu will be very easy. I've just written these generators in ruby, but it can be rewritten in python, perl, etc. On Wed, 8 Jan 2020 at 17:06, puchuu