Adrian,
m68k/mm only has syscall_trace() (in kernel/ptrace.c) which is called
from the system call entry in kernel/entry.S (look for do_trace_* there).
syscall_trace() is called before and after syscall execution (if the
syscall trace flag is set). Looking at the sparc 32 and 64 bit trace
code for comparison, you might try replacing these calls by
syscall_trace_enter() and syscall_trace_leave(). The current code in
syscall_trace replicates the code in ptrace_report_syscall which will be
called from syscall_trace_enter() and syscall_trace_leave(), so things
ought to continue to function as normal.
syscall_trace() is also called from the ret_from_signal entry - no idea
what should happen to that one. My guess is to treat this as syscall
trace exit.
CC to Andreas - maybe there are subtleties with strace or gdb that I'm
missing.
Cheers,
Michael
On 23/07/20 10:03 PM, John Paul Adrian Glaubitz wrote:
Hello!
Michael and I have been working on SECCOMP in SuperH and successfully added
the missing pieces yesterday [1].
We're now looking into what needs to be done for m68k and I have noticed that
syscall_trace_enter and syscall_trace_leave - which needs to be touched for
SECCOMP support - are available on ColdFire and non-MMU targets for m68k.
Is there a particular reason for that? Looking at 68000/entry.S, I can see
that both functions are invoked [2] so I'm not sure why they are built
for CONFIG_COLDFIRE and !CONFIG_MMM only.
Any ideas?
Adrian
[1] https://marc.info/?l=linux-sh&m=159546012829989&w=2
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/m68k/68000/entry.S
