On 10/10/18, Eugene Syromiatnikov <esyr@xxxxxxxxxx> wrote: > On Tue, Jul 24, 2018 at 08:39:57PM +0300, Yury Norov wrote: >> Hi all, >> >> + Pavel Machek, Palmer Dabbelt, Wookey. >> >> On Wed, May 16, 2018 at 11:18:45AM +0300, Yury Norov wrote: >> > This series enables AARCH64 with ILP32 mode. >> > >> > As supporting work, it introduces ARCH_32BIT_OFF_T configuration >> > option that is enabled for existing 32-bit architectures but disabled >> > for new arches (so 64-bit off_t userspace type is used by new >> > userspace). >> > Also it deprecates getrlimit and setrlimit syscalls prior to prlimit64. >> > >> > Based on kernel v4.16. Tested with LTP, glibc testsuite, trinity, >> > lmbench, >> > CPUSpec. > >> This is the update of the series based on 4.17 kernel >> https://github.com/norov/linux/tree/ilp32-4.17 > > Hello. > > I have some questions regarding AArch64 ILP32 implementation for which I > failed to find an answer myself: > * How ptrace() tracer is supposed to distinguish between ILP32 and LP64 > tracees? For MIPS N32 and x32 this is possible based on syscall > number, but for AArch64 ILP32 I do not see such a sign. There's also > ARM_ip is employed for signalling entering/exiting, I wonder whether > it's possible to employ it also for signalling tracee's personality. Don't know. > * 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. The idea is to keep the syscall entry points as similar as possible between arm (aarch32) emulation and aarch64-ilp32 mode when you have a kernel that supports both. Arnd
