Re: [RFC/PATCH] Implement new PTRACE_EVENT_SYSCALL_{ENTER,EXIT}

[Roland McGrath <roland@hack.frob.com>]

> I won't argue, but it is not clear to me if this is really useful,
> given that the debugger can read the regs.

I do see the utility of having a consistent machine-independent way to get
the syscall number from userspace.  But note that this could be probably
accomplished with just a uapi header change, providing an inline or macro
to extract the syscall number from the regset data.  (It was once the case
that there were some machines where the syscall number is not in any
register and has to be extracted by decoding the instruction.  I'm not sure
if that is still an issue anywhere.)

Also note that adding a separate copy of the syscall number introduces a
new wrinkle into the interface.  This might be considered to be good, bad,
or indifferent, but I think it should at least be considered explicitly.
That is, at the entry stop the syscall number (when it's in a register) can
be changed via ptrace.  So if the number is delivered via ptrace_message,
that's a separate copy of the original number that does not reflect any
changes made via ptrace--so it reflects what userland asked for, as opposed
to what the kernel actually acted on.

I don't have a particular opinion about which way to go with that.
I just wanted all the issues (I'm aware of) to be considered.

I absolutely concur that all new tracing features should work in the
existing style of PTRACE_EVENT_* that a PTRACE_O_* flag enables it and
then it applies for all kinds of running under ptrace.  Things like
PTRACE_SYSCALL that combine what-to-report with how-to-run are terrible
and should never be done again.


Thanks,
Roland