Q: UTRACE_SYSCALL_RESUMED logic

[Roland McGrath]

> 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