[strace/strace] [RFC] Add 64-bit LoongArch support (PR #205)

[Dmitry V. Levin]

> I'm puzzled here. I think the original problem is if syscall_enter_from_user_mode() return -1 by ptrace we should make the syscall return -ENOSYS. And we don't need to do anything if tracehook_report_syscall_entry() return 0. Because if tracehook_report_syscall_entry() return 0, then syscall_enter_from_user_mode() also return 0 (there is no SYSCALL_WORK_SYSCALL_EMU on LoongArch), and then do_syscall() will do the real syscall.

The problem is that `syscall_enter_from_user_mode` does a few different things but has a single return value - the new syscall nr. In particular, it calls both `arch_syscall_enter_tracehook` and `__secure_computing`, each of them can change pt_regs, but they have different semantics: while `__secure_computing` is guaranteed to call `syscall_set_return_value` e.g. in case of `SECCOMP_RET_ERRNO`, `arch_syscall_enter_tracehook` has no such option because `syscall_set_return_value` is not exposed to userspace and regs[4] is used for different purposes on entering and exiting syscall.

btw, another problem with the current implementation of `do_syscall` is that unlike other architectures, here the ptracer cannot change the first syscall argument on entering syscall.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/strace/strace/pull/205#issuecomment-1008265907
You are receiving this because you are subscribed to this thread.

Message ID: <strace/strace/pull/205/c1008265907 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20220109/5f89df85/attachment.htm>