On Sat, Oct 13, 2018 at 04:07:31AM +0200, Eugene Syromiatnikov wrote:

On Wed, Oct 10, 2018 at 03:39:07PM +0100, Szabolcs Nagy wrote:

quoted

On 10/10/18 15:10, Eugene Syromiatnikov wrote:

quoted

 * What's the reasoning behind capping syscall arguments to 32 bit? x32
   and MIPS N32 do not have such a restriction (and do not need special
   wrappers for syscalls that pass 64-bit values as a result, except
   when they do,  as it is the case for preadv2 on x32); moreover, that
   would lead to insurmountable difficulties for AArch64 ILP32 tracers
   that try to trace LP64 tracees, as it would be impossible to pass
   64-bit addresses to process_vm_{read,write} or ptrace PEEK/POKE.

but that's necessarily the case for all ilp32 abis:
the userspace syscall function receives 32bit
arguments so even if the kernel abi takes 64bit
args you cannot use that from c code. (the libc
does not even know which args should be sign or
zero extended.)

glibc's syscall() prototype has kernel_ulong_t as its arguments (more
specifically, to __syscall_ulong_t, which is 64-bit wide on x32; it
should also have kernel_long_t as its return type instead of long,
but that's another story), so it works perfectly fine in case of x32.

This would have been my preferred approach but the libc community were
not entirely happy with it as it breaks POSIX compatibility:

https://sourceware.org/bugzilla/show_bug.cgi?id=16437
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/323348.html

(there are other threads around x32 and people arguing whether POSIX is
wrong)

Some sometime around version 4 or 5 of this series, we made the move
(back) to compat-like ABI.

-- 
Catalin