gdbstub/uprobes problems: uprobe_unregister with halted target

[Srikar Dronamraju]

* Jim Keniston <jkenisto at us.ibm.com> [2009-08-03 11:10:00]:

> > 
> > 
> > So as per my analysis, gdb_utrace_report_signal was called, followed by
> > uprobe_report_signal. Since gdb_utrace_report_signal requested for
> > UTRACE_STOP as resume action for SIGTRAP, the thread got stopped.
> > uprobes was waiting for either the singlestep to occur (or the process to
> > exit/exec or some other event) before it could signal the process to be
> > quiesced. 
> 
> Uprobes attempts to handle this situation.  Before returning
> (UTRACE_SINGLESTEP | UTRACE_SIGNAL_IGN), uprobe_report_signal()
> registers to be notified of quiesce events.  If report_signal for some
> other engine (e.g., gdbstub's) requests a UTRACE_STOP, that'll override
> uprobe_report_signal()'s UTRACE_SINGLESTEP.  But uprobe_report_quiesce()
> should get called as a result and re-assert UTRACE_SINGLESTEP.  Assuming
> gdbstub's report_quiesce callback eventually returns something other
> than UTRACE_STOP, the UTRACE_SINGLESTEP should take effect.
> 
> That was my thinking, anyway.  I can't guarantee that it actually works
> that way.
> 

If we refer to the discussion between you and Roland 
https://www.redhat.com/archives/utrace-devel/2008-July/msg00063.html

I understand this as:
If quiesce event is requested on a stopped thread, then report_quiesce
(in this case uprobe_report_quiesce) will only be called when the thread
starts to run but before it reaches user space.  It also seems quiesce
event on stopped threads is only useful, if one or more engines request
a UTRACE_REPORT or UTRACE_INTERRUPT.

However do correct me if I have misunderstood your discussion.

Additionally please refer my mail to utrace-devel here.
https://www.redhat.com/archives/utrace-devel/2009-March/msg00006.html
I had reported that on resume, I have noticied that singlestep being
ignored. 

So even if the program was resumed, there are chances that singlestep
will not occur, resulting in the program existing prematurely.

--
Thanks and Regards
Srikar