> > This seems like something we could change upstream first, to clarify and > > separate the behavior change. If the arch bits about choosing si_code et > > al are resolved, then it is simple to make the old kernel's tracehook calls > > post a signal instead of using ptrace_notify. > > Ah, yes. I forgot about si_code/etc filling. > > Of course, the discussed change which kills PTRACE_EVENT_SIGTRAP has to > fill *info correctly too.
Yes. We previously discussed si_code et al in the context of what utrace-ptrace could do, and that's when I first raised having some kind of arch hook for it. My suggestion above assumed that we'd invent the arch hook to use first in the upstream version in such a way that it would be natural to use the same hook in utrace-ptrace. Thanks, Roland