On 11/10, Roland McGrath wrote: > > Ok. I realize it's largely separate, but I think we want to hash through > this along with the other set of after-report-behavior problems. > > Also, it doesn't seem sensible to fiddle with utrace_report_syscall_entry > separate from resolving UTRACE_SYSCALL_RESUMED change to the API. There > was not much feedback about that change, but IIRC nobody was against it. > So I've decided to merge the old utrace-syscall-resumed branch into > utrace-cleanup.
I saw you have utrace-syscall-resumed branch but never looked at it. I'll try to follow these changes once I fix utrace-ptrace. Now that upstream problems with syscall_exit && trap are hopefully resolved this should be easy. Today I was distracted by workqueue bug (bluetooth driver actually), will try tomorrow. Roland, I guess utrace-cleanup becomes the "master" branch, yes? I mean, utrace-ptrace should be updated according to the recent changes in utrace-cleanup, and this is what you are going to send upstream. This means you should also merge utrace-cleanup into utrace-ptrace? Then I fix utrace-ptrace. I _think_ this will be easy too. ptrace_report_syscall_exit() can notice ctx->resume == UTRACE_SINGLESTEP and send the trap if utrace_control() doesn't set TIF_SINGLESTEP "synchronously". (And this means with utrace tracehook_report_syscall_exit() can do nothing except utrace_report_syscall_exit()). Oleg.
