Gdb currently uses architecture-specific hooks to determine the syscall number at syscall-enter-stop and syscall-exit-stop, typically getting the value from a register or parsing the syscall instruction.

One difficult case to get right is execve syscall-exit-stop.  See for instance for powerpc: commit ec6d0dde71d7 ("powerpc: Enable execve syscall exit tracepoint").

I've written a gdb patch to start using PTRACE_GET_SYSCALL_INFO in preference to the architecture-specific hooks, but found that for PTRACE_SYSCALL_INFO_EXIT no syscall number is available.

Apparently FreeBSD's ptrace does support this.

I've written another gdb patch that adds a caching scheme, caching the syscall number at syscall-enter-stop and reusing it at syscall-exit-stop.

A problem with the caching scheme though is that it doesn't help if there's a syscall-exit-stop without preceding syscall-enter-stop, for instance because syscall tracing was not enabled yet, and gdb was using PTRACE_CONT instead of PTRACE_SYSCALL.  Another possibility that could cause this situation is attaching in the middle of a syscall, though I'm not sure if this is possible.

So, even with a kernel supporting PTRACE_GET_SYSCALL_INFO, and a caching scheme, gdb still needs to rely on the architecture-specific hooks for the exceptional cases.

If we'd have the syscall number available in PTRACE_SYSCALL_INFO_EXIT, we wouldn't need this caching scheme and would only have to rely on architecture-specific hooks for older kernels not supporting this.