Date: Thu, 20 May 2021 08:51:53 +1000 From: Nicholas Piggin <npiggin@...il.com> To: "Dmitry V. Levin" <ldv@...linux.org>, Michael Ellerman <mpe@...erman.id.au> Cc: Joakim Tjernlund <Joakim.Tjernlund@...inera.com>, libc-alpha@...rceware.org, libc-dev@...ts.llvm.org, linux-api@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org, Matheus Castanho <msc@...ux.ibm.com>, musl@...ts.openwall.com Subject: Re: Linux powerpc new system call instruction and ABI Excerpts from Dmitry V. Levin's message of May 19, 2021 11:26 pm: > On Wed, May 19, 2021 at 08:59:05PM +1000, Nicholas Piggin wrote: >> Excerpts from Dmitry V. Levin's message of May 19, 2021 8:24 pm: >> > On Wed, May 19, 2021 at 12:50:24PM +1000, Nicholas Piggin wrote: >> > [...] >> >> With this patch, I think the ptrace ABI should mostly be fixed. I think >> >> a problem remains with applications that look at system call return >> >> registers directly and have powerpc specific error cases. Those probably >> >> will just need to be updated unfortunately. Michael thought it might be >> >> possible to return an indication via ptrace somehow that the syscall is >> >> using a new ABI, so such apps can be updated to test for it. I don't >> >> know how that would be done. >> > >> > Is there any sane way for these applications to handle the scv case? >> > How can they tell that the scv semantics is being used for the given >> > syscall invocation? Can this information be obtained e.g. from struct >> > pt_regs? >> >> Not that I know of. Michael suggested there might be a way to add >> something. ptrace_syscall_info has some pad bytes, could >> we use one for flags bits and set a bit for "new system call ABI"? > > PTRACE_GET_SYSCALL_INFO is an architecture-agnostic API, it hides all > architecture-specific details behind struct ptrace_syscall_info which has > the same meaning on all architectures. ptrace_syscall_info.exit contains > both rval and is_error fields to support every architecture regardless of > its syscall ABI. > > ptrace_syscall_info.exit is extensible, but every architecture would have > to define a method of telling whether the system call follows the "new > system call ABI" conventions to export this bit of information. It's already architecture speicfic if you look at registers of syscall exit state so I don't see a problem with a flag that ppc can use for ABI. > > This essentially means implementing something like > static inline long syscall_get_error_abi(struct task_struct *task, struct pt_regs *regs) > for every architecture, and using it along with syscall_get_error > in ptrace_get_syscall_info_exit to initialize the new field in > ptrace_syscall_info.exit structure. Yes this could work. Other architectures can just use a generic implementation if they don't define their own so that's easy. And in userspace they can continue to ignore the flag. > >> As a more hacky thing you could make a syscall with -1 and see how >> the error looks, and then assume all syscalls will be the same. > > This would be very unreliable because sc and scv are allowed to intermingle, > so every syscall invocation can follow any of these two error handling > conventions. > >> Or... is it possible at syscall entry to peek the address of >> the instruction which caused the call and see if that was a >> scv instruction? That would be about as reliable as possible >> without having that new flag bit. > > No other architecture requires peeking into tracee memory just to find out > the syscall ABI. This would make powerpc the most ugly architecture for > ptracing. > > I wonder why can't this information be just exported to the tracer via > struct pt_regs? It might be able to, I don't see why that would be superior though. Where could you put it... I guess it could go in the trap field in a high bit. But could that break things that just test for syscall trap number (and don't care about register ABI)? I'm not sure. Thanks, Nick
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.