> do_ptrace_notify_stop() doesn't change ->ptrace_message if the new > value is zero. Not sure what I was thinking about when I wrote this.
Perhaps you were thinking of the upstream code before tracehook.h was introduced. Ancient code left whatever was in ptrace_message before there for the "0" cases. When I made everything use ptrace_event(), the semantics changed to yield 0 rather than last-event's-unrelated-value for PTRACE_GETEVENTMSG after events that don't really have a message word. > - ptrace_event() always sets ->ptrace_message, this is OK Right. > - ptrace_report_syscall() and tracehook_signal_handler() > call ptrace_notify() directly which doesn't change > ->ptrace_message, this means PTRACE_GETEVENTMSG reports > the previous value. > > This looks a bit strange to me. Should we keep this > behaviour? Or can we return 0? Even better, we could > put somehing useful into ->ptrace_message, say, syscall > number. I think we can set it to 0. It's the same change we made by introducing ptrace_event() for the other cases, and nobody complained. > - jctl stop doesn't change ->ptrace_message too. Again, > can the new code return 0? I think so. > This all is very minor, I am asking just in case. Right, diligence appreciated! It might be wisest to send the trivial changes to clear ptrace_message in those cases upstream first so that we match the semantics exactly. Thanks, Roland
