> Hmm. If task is not stopped then it is current (except > utrace_control(DETACH) can play with the dying task).
Right, asynchronous detach was the problematic case I was concerned with. > If this is not safe, what about finish_resume_report() ? Well, that is a clearly safe and proper spot to do it. But the whole problem we have is that we aren't getting to that path when we've done a detach, right? > > > However, I am starting to think that if you prefer this change we > > > have a better option. Instead of duplicating UTRACE_RESUME logic, > > > perhaps the patch below makes more sense? > > > > Hmm, that does seem like it might be pretty reasonable. If your > > engine had ever permitted the tracee to get back to user mode after > > requesting UTRACE_*STEP, then it's just desserts to cause that SIGTRAP > > regardless of whether other engines might have kept it stopped in > > actuality. > > Not sure I understand what you mean. I'm not all that sure any more either. ;-) (It's now pretty early in the morning out of my native timezone, so take everything I say today with a grain of salt.) > But this patch looks reasonable to me too. It translates the current > "There might not be another report before it just resumes" comment in > utrace_control(UTRACE_RESUME) into the plain C code. And solves the > original problem with SINGLESTEP after DETACH (but not all problems). Ok. I'll go with your sense on this, and we can keep fixing it up later. > I tried to test them all. But I think that your review is much more > useful, apart from ptrace-tests I do not know what else I can use > for the testing. Well, that's a nice theory. But I may not be thinking especially clearly this week. So we'll just have to see how it goes. > I'll send the last patch in a minute. Ok, I'm merging it now. Thanks, Roland
