On Sat, Oct 13, 2018 at 10:34:11AM +0100, Catalin Marinas wrote: > > Lines: 73 > > External Email > > On Sat, Oct 13, 2018 at 04:14:16AM +0200, Eugene Syromiatnikov wrote: > > On Wed, Oct 10, 2018 at 04:36:56PM +0100, Catalin Marinas wrote: > > > On Wed, Oct 10, 2018 at 04:10:21PM +0200, Eugene Syromiatnikov wrote: > > > > 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. > > > > > > With the current implementation, I don't think you can distinguish. From > > > the kernel perspective, the register set is the same. What is the > > > use-case for this? > > > > Err, a ptrace()-based tracer trying to trace a process, for example? > > I first thought it wouldn't matter for ptrace-based tracers since the > syscall numbers are (mostly) the same. But the arguments layout in > register is indeed different, so I see your point now about having to > distinguish. > > > > We could add a new regset to expose the ILP32 state (NT_ARM_..., I can't > > > think of a name now but probably not PER* as this implies PER_LINUX_... > > > which is independent from TIF_32BIT_*). > > > > So that would require an additional ptrace() call on each syscall stop, > > is that correct? > > The ILP32 state does not change at run-time, so it could only do a > ptrace() call once and save the information. No need to re-read it on > each syscall stop. > > We could set a high bit in the syscall number reported to the ptrace > caller (though not changing the syscall ABI) but I haven't thought of > other consequences. For example, can the ptrace caller change the > syscall number? I believe, /proc/PID/auxv is enough to distinguish between arm64, ilp32 and aarch32 ABis. If no, I think it's better to do it there. I don't have ILP32 machine available at the moment, but I'll check it soon. > > > > * 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. > > > > > > We've attempted in earlier versions to allow a mix of 32 and 64-bit > > > register values from ILP32 but it got pretty complicated. The entry code > > > would need to know which registers need zeroing of the top 32-bit > > > > If kernel specifies 64-bit wide registers for syscalls, then it's the > > caller's (libc's) responsibility to properly sign-extend arguments when > > needed, and glibc, for example, already has proper type definitions that > > aimed to handle this. > > We tried, see my other reply. A couple of links to recall the story: https://www.spinics.net/lists/linux-s390/msg11593.html http://linux-kernel.2935.n7.nabble.com/RFC6-PATCH-v6-00-21-ILP32-for-ARM64-td1345105.html Cover-letter of the series has links to previous discussions. I would also notice that even if we pass 64-bit parameters in a single register, we cannot avoid using the compat layer. It looks more natural not to split the 64-bit register, but from performance point of view there is almost no difference, either we split registers or not (2.6% for empty syscall, as I measured). And the cost of overcomplication was considered too much. So we chose to stick to more standard compat layer and gain in maintainability. Yury