> > 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

Reply via email to