utrace_control(,,UTRACE_SINGLESTEP)

[Roland McGrath]

[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