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

[Huacai Chen]

> > Hmm, can we keep do_syscall() as is and solve the ptrace problem by overriding arch_syscall_enter_tracehook() like this?
> > static inline __must_check int arch_syscall_enter_tracehook(struct pt_regs *regs) {
> > ```
> >     ret = tracehook_report_syscall_entry(regs);
> > 
> >     if (ret)
> >             syscall_set_return_value(current, current_pt_regs(), -ENOSYS, 0);
> > ```
> 
> It's better to use `regs` instead of `current_pt_regs()` here.
> 
> > ```
> > return ret;
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > ```
> > 
> > }
> > ```
> 
> No, this cannot help to solve the problem because syscall tampering doesn't make `tracehook_report_syscall_entry` return a nonzero value.
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.

> 
> However, this approach makes sense for a different reason - the lengthy comment before `tracehook_report_syscall_entry` says: _Returns zero normally, or nonzero if the calling arch code should abort the system call. That must prevent normal entry so no system call is made. If @task ever returns to user mode after this, its register state is unspecified, but should be something harmless like an %ENOSYS error return._



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

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