On 08/12, Srikar Dronamraju wrote: > > Thanks for the quick patch. > > > I think this might be the right fix. First, we change the order so that > > UTRACE_INTERRUPT prevails over UTRACE_REPORT. (I'm really not sure why I > > ever had it the other way around.) Next, we keep track of not only whether > > one engine wanted a report when another wanted stop, but of the prevailing > > resume action (i.e. least value still > UTRACE_STOP). After stopping and > > resuming, we apply UTRACE_INTERRUPT or UTRACE_REPORT as needed to make sure > > we get the kind of resume report we need. > > I applied your patch. However it doesnt seem to fix the problem. > i.e I see the program still continuing with resume and I dont see any > more callbacks being made. > > ---------------------------------------------------------------------- > In probe5_a init_module > In probe5_b init_module > In probe5_a engine_a_report_signal ffff880206ef9708 signr=5 action=35 ret=10 > In probe5_a engine_a_report_signal ffff880206ef9948 signr=5 action=10 ret=13 > In probe5_a cleanup_module > --------------------------------------------------------------------- > > -- > Thanks and Regards > Srikar > > PS: Changes in probe5_a and probe5_b are > 1. remove duplicate print statements in report_signal callbacks. > 2. cache the return from report_signal and use it with > utrace_resume_action in report_quiesce.
Could you show the code please? I don't really understand how it looks with 1+2 above. But, just in case... I think module_b should re-assert SINGLESTEP from either report_quiesce/report_signal. Btw. Roland, unless utrace_get_signal() does dequeue_signal(info), we pass a random value in info->si_signo to ->report_signal(). Yes, _if_ I understand correctly, report_signal can check action, but perhaps it makes sense to set ->si_signo = 0, this may help to engine writers. For example, probe5_a and probe5_b just blindly check ->si_signo. Oleg.
