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

Huacai Chen notifications at github.com
Wed Jan 12 08:39:32 UTC 2022


> On Sun, Jan 09, 2022 at 05:58:44AM -0800, Huacai Chen wrote: > > With @chenhuacai's [latest patch]([xen0n/linux at 593f8c0](https://github.com/xen0n/linux/commit/593f8c0180fc1056e3ea0ca91ce9a8096f40b7ef)), every test passes except this: > > Yes, this looks plausible. > > As I said earlier, another problem with the current implementation of `do_syscall` is that unlike other architectures, here the ptracer cannot change the first syscall argument because it is currently stored in `regs->orig_a0` which is out of reach of ptracers. What do you think about exposing `regs->orig_a0` to ptracers? Exposing orig_a0 means modifying user_pt_regs, gpr_get(), gpr_set() and all tracers (gdb, strace, etc) and don't need to overriding arch_syscall_enter_tracehook(), right?
> Yes, exposing orig_a0 means modifying user_pt_regs, gpr_get(), gpr_set(), and all tracers. This would allow to do regs->regs[4] = -ENOSYS; in do_syscall() right before the syscall_enter_from_user_mode() invocation, and there won't be any need to override arch_syscall_enter_tracehook() then.

Hmm, there is a more simple solution, overide arch_syscall_enter_tracehook() as below:

static inline __must_check int arch_syscall_enter_tracehook(struct pt_regs *regs)
{
        int ret = tracehook_report_syscall_entry(regs);

        regs->orig_a0 = regs->regs[4];
        syscall_set_return_value(current, regs, -ENOSYS, 0);

        return ret;
}


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

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


More information about the Strace-devel mailing list