[Bug tdep/28623] Missing catching return of execve syscall of PowerPC

["ulrich.weigand at de dot ibm.com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28623

--- Comment #7 from ulrich.weigand at de dot ibm.com ---
This is certainly better, but still somewhat fragile in that it still requires
the platform back-end to reliably detect that it cannot detect the system call
number.  On some targets (e.g. s390x) that read the system call number from
memory as immediate operand of the syscall instruction, you may encounter the
even worse scenario that after an execve you *do* detect a syscall but it is
wrong (because at that same location in memory the new executable also contains
a syscall instruction, but a different one) ...

I still think ideally we should be able to make use of the PTRACE_EVENT_EXEC
reported by the kernel.  If I'm reading kernel code correctly, we should be
getting the following sequence of ptrace events:
 - syscall SIGTRAP - before execve
 - PTRACE_EVENT_EXEC
 - syscall SIGTRAP - after execve

So maybe processing of PTRACE_EVENT_EXEC should set a flag that if syscall
traps are active, the immediate next such event in the current process should
not even attempt to call gdbarch_get_syscall_number, but simply assume that it
is a return of the immediately preceding execve syscall.

-- 
You are receiving this mail because:
You are on the CC list for the bug.