On 08/14, Roland McGrath wrote:
- minor, but it is possible that tracehook_notify_jctl() will
be called before tracehook_get_signal(). Not a real problem,
but shouldn't UTRACE_STOP mean stop as soon as possible ?
No. It means stop before this thread can newly cause any
Btw. Roland, unless utrace_get_signal() does dequeue_signal(info),
we pass a random value in info-si_signo to -report_signal().
Yes, _if_ I understand correctly, report_signal can check action,
but perhaps it makes sense to set -si_signo = 0, this may help to
engine writers.
This is really
Because you forgot to add QUIESCE to utrace_set_events's mask !!!
D'oh!
Perhaps it makes sense to have utrace_control() fail with -EINVAL or
something when you try anything but RESUME or DETACH when you do not have
UTRACE_EVENT(QUIESCE) set.
Thanks,
Roland
Agreed, this looks like a right change to me. In any case I think this makes
the code more understandable and logical, and -resume_action is much better
than -reports imho.
Ok.
But, you seem to forget to fix other callers of utrace_stop(),
Yes, it was not a complete patch, just to get your
Hmm. I think this is not exacly right. Suppose that
report-action == UTRACE_INTERRUPT but utrace-interrupt is already set.
In that case, since UTRACE_INTERRUPT = UTRACE_REPORT, we set -report.
Not really bad, but not right anyway.
Ah, true. It enables harmless but superfluous work.
I've
On 08/11, Roland McGrath wrote:
I think this might be the right fix. First, we change the order so that
UTRACE_INTERRUPT prevails over UTRACE_REPORT. (I'm really not sure why I
ever had it the other way around.)
and this is consistent with the behaviour utrace_resume() which does nothing
if
On 08/11, Roland McGrath wrote:
@@ -1298,14 +1305,14 @@ static void finish_report(struct utrace_
{
bool clean = (report-takers !report-detaches);
- if (report-action = UTRACE_REPORT !utrace-report) {
- spin_lock(utrace-lock);
- utrace-report = 1;
-
On 08/12, Srikar Dronamraju wrote:
Thanks for the quick patch.
I think this might be the right fix. First, we change the order so that
UTRACE_INTERRUPT prevails over UTRACE_REPORT. (I'm really not sure why I
ever had it the other way around.) Next, we keep track of not only whether
Could you show the code please? I don't really understand how it
looks with 1+2 above.
I am attaching the code.
The module code is in try_utrace/probe5_a.c and try_utrace/probe5_b.c.
But, just in case... I think module_b should re-assert SINGLESTEP
from either
Aaahhh. Srikar, I spent 3 hours trying to understand
Your code does NOT reassert SINGLESTEP. Of course, -report_signal
is not called again, utrace_get_signal() just clears -report when
it is called after wakeup.
Because you forgot to add QUIESCE to utrace_set_events's mask !!!
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
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,
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.
13 matches
Mail list logo
