resume from another engine results in loss of singlestep req.

2009-08-11 Thread Srikar . Dronamraju
Hi Roland, If we have two utrace engines for a thread with first engine requesting UTRACE_STOP and second one requesting UTRACE_SINGLESTEP, utrace correctly gives priority to UTRACE_STOP. However when the first engine detaches(or resumes) the singlestep request from the second engine is not

Re: resume from another engine results in loss of singlestep req.

2009-08-11 Thread Roland McGrath
The intent is that if you asked for UTRACE_SINGLESTEP (or anything else but plain UTRACE_RESUME), you should be guaranteed another callback after a stop and resumption, i.e. after any time that the resume action you asked for was implicitly lost. Perhaps the following patch fixes it? Thanks,

Re: resume from another engine results in loss of singlestep req.

2009-08-11 Thread Roland McGrath
Not only UTRACE_SINGLESTEP... UTRACE_REPORT can't be lost, we have utrace_report-reports. But what about UTRACE_INTERRUPT ? IOW, should any callback ever return (say) UTRACE_INTERRUPT instead of utrace_control(UTRACE_INTERRUPT) ? Indeed I think this is handled wrong in the current code.

Re: Q: ptrace_detach() UTRACE_DETACH

2009-08-11 Thread Roland McGrath
I don't understand why this is better than just changing -ops. Except, yes, I agree with above. Sure, if you think about the innards they amount to about the same thing. After PTRACE_DETACH, there is one engine attached and it uses the special ops vector. They are really just different ways to