[PATCH 0/3] UTRACE_DETACH fixes

[Roland McGrath]

> Hmm. I am not sure I understand. If ->report_signal != NULL, then
> you can't expect ->report_quiesce() after utrace_control(INTERRUPT) ?

Sorry, I used "report_quiesce" as shorthand for "either report_quiesce, or
report_signal with UTRACE_SIGNAL_REPORT".

> > So, it is technically kosher enough to use UTRACE_INTERRUPT without
> > UTRACE_EVENT(QUIESCE) set, if you really know the situation and are sure
> > about all those caveats above.
> 
> How? see below.

I mentioned the examples.

> > But, it's only UTRACE_EVENT(QUIESCE) that
> > gives you any expectation of an "extra" callback for "no event" from either
> > UTRACE_REPORT or UTRACE_INTERRUPT.
> 
> Yes, this is clear too.

Apparently not. ;-)

> So. Now I am even more confused. First of all, ugdb (at least currently)
> does not need report_quiesce() and UTRACE_EVENT(QUIESCE) at all. OK, this
> is not 100% true due to multitracing/etc, lets ignore this. Anyway it
> makes sense to clear QUIESCE after $c to avoid the unnecessary callbacks.
> 
> All it needs is ->report_signal(). But, the problem is, it is not called
> after utrace_control(INTERRUPT) ! You need QUIESCE to ensure report_signal()
> will be called, and this looks at least strange to me.

QUIESCE is the only event type for "no event".  If you only asked for
signal events, then you only get a callback when there is an actual signal
event.  If you want an extra callback before dequeuing any signal, then
that is what QUIESCE is for.

> Once again, I am not asking to change utrace now, but could you explain
> what is wrong with the patch below?

That gives an extra unrequested report_signal callback to every engine that
is only interested in some signal event.  Consider a "crash-catcher"
engine.  It would only track UTRACE_EVENT(SIGNAL_CORE) (and perhaps CLONE
for its bookkeeping).  This engine never asked for a callback before each
and every attempt to dequeue any signal, which is what you would give it
with your change.


Thanks,
Roland