> Just can't understand UTRACE_SYSCALL_RESUMED code. You understand too well! :-)
> To the pointed, I tried to read the docs: > > * When %UTRACE_STOP is used in @report_syscall_entry, then @task > * stops before attempting the system call. In this case, another > * @report_syscall_entry callback follows after @task resumes; > > Probably I misread this comment, or code (or both) but this is not > what utrace_report_syscall_entry(). No, the comment is wrong. I probably wrote it during one iteration of the API idea and then thought of different nits while writing the code. > This can happen if, during the first report, one engine returns > UTRACE_STOP and another engine returns UTRACE_REPORT. > > Or, no matter how many engines we have, the tracer uses UTRACE_REPORT > to wakeup the tracee after SYSCALL_ENTRY stop. Right, that's the intent. > In any case, what is the rationality? The rationale is that if you see utrace_resume_action(action)==UTRACE_STOP in your callback, then you know another engine asked for stop and you can decide to return UTRACE_REPORT if you want to see the UTRACE_SYSCALL_RESUMED notification after the other engine resumes. If you aren't delaying your consideration of the event until the UTRACE_SYSCALL_RESUMED case because you don't care, then you don't return UTRACE_REPORT and are not guaranteed the second report. > And how can we trust "if (utrace->resume == UTRACE_REPORT)" ? > If we have multiple engines, some engine can use UTRACE_INTERRUPT ? That's why it should be <= instead. (I just noticed this while poking at the stop/step issues, but it's not related to that, only to this.) I did this and changed the comment in de5a46ea. Is that clear now? Thanks, Roland