On Tue, 14 Jan 2025, Dmitry V. Levin wrote: > > How did you produce these results? > > $ PATH="$HOME/x-tools/mips64-unknown-linux-gnu/bin:$PATH" make -j`nproc` ARCH=mips CROSS_COMPILE=mips64-unknown-linux-gnu- -C tools/testing/selftests TARGETS=ptrace USERLDFLAGS='-static' USERCFLAGS='-mabi=32' > $ echo init |(cd tools/testing/selftests/ptrace && ln -snf get_syscall_info init && cpio --dereference -o -H newc -R 0:0) |gzip >get_syscall_info.mips-o32.img > $ qemu-system-mips -nographic -kernel vmlinuz -initrd get_syscall_info.mips-o32.img -append 'console=ttyS0' > > Likewise for mips64, but the patch for kselftest_harness.h from [1] > is needed to see correct mismatch values in the test diagnostics. > > [1] https://lore.kernel.org/all/20250108170757.GA6723@xxxxxxxxx/ Thanks, I'll try to see what's going on with `get_user'. > > The patch is definitely broken, the calling convention is the same > > between n32 and n64: 64-bit arguments in $4 through $11 registers as > > required, and your change makes n32 truncate arguments to 32 bits. > > There must be something very specific to n32 then: apparently, > __kernel_ulong_t is a 32-bit type on n32, so the syscall arguments are > 32-bit values, at some point (in glibc?) they get sign-extended from 32 to > 64 bits, and syscall_get_arguments returns them as 64-bit values different > from the original syscall arguments, breaking the test. This matters at least for `lseek', which has an `off64_t' aka `long long' argument on n32 (there's no `_llseek' on n32). Since arguments are passed via 64-bit registers and a `long long' datum is held in just one this is transparent between n32 and n64 (of course on n64 this corresponds to the plain `long' data type, so the kernel, which is always n64 for 64-bit configurations, sees the incoming argument as `long', and the same stands for the outgoing return value). Surely non-LFS lseek(2) will produce the syscall's `long long' argument truncated (cf. sysdeps/unix/sysv/linux/mips/mips64/n32/lseek.c in glibc), but both LFS lseek(2) and lseek64(2) will pass the native value on n32. > If this is the expected behaviour, then I'd have to add an exception for > mips n32 both to the kernel test and to strace that uses this interface. Is MIPS n32 the only psABI across all our architectures supported that can have `long long' syscall arguments? I guess it might actually be the case, in which case I won't be surprised it needs specific handling. Maciej