[I have no idea why you appended this to that message introducing patches that are not related to this at all. Please use separate threads for separate topics, and choose clearly apropos Subject: lines.]
> I am thinking how can we fix utrace_control(SINGLESTEP). I don't > have good ideas so far. But, perhaps we can add > utrace->please_enable_single_step:1 ? If anything like this, it would be an enum utrace_resume_action field. Otherwise you are changing the API fundamentally. > utrace_stop() and utrace_finish_jctl() can check this flag after wakeup What you mean here is an API where utrace_control's choice of resume_action takes effect without further callbacks when nothing else has requested any. As always, I want a discussion of the API semantics to be clear and separate from implementation details. > Or, we can use ENGINE_SINGLESTEP, which probably makes more sense. > Like ENGINE_STOP, it lives both in engine->flags and ->utrace_flags. This takes us back to the old old utrace API where we had sticky state bits for the things that are now represented in utrace_resume_action. That is a very bad API choice IMHO, and its inherent unpleasantnesses are why we abandoned it before. > I no longer think utrace_control() should just turn SINGLESTEP into > REPORT silently. IMHO this characterization misrepresents what the API is today, and glosses over the real complexities that are why it is that way. There is no "silent" about it. If things are going on that affect what you asked for, then you get a callback to decide what you really want. The inability to react to other engines' effects this way was one of the major failings of the old "sticky action bits" API. The other thing that was completely wrong about sticky "action state bits" for single-step and block-step is that they are inherently just not sticky states. Each is a one-shot action that leads to a single provoked event (at most). It just doesn't make sense to represent them as states. Thanks, Roland
