Hi - On Mon, Aug 03, 2009 at 11:10:00AM -0700, Jim Keniston wrote: > [...] > > 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. > > [...]
A variant of this problem still exists, despite switching to a deferred uprobes-unregister operation (now done at gdb-disconnect time), but even then sometimes the process is stopped mid-singlestep. It seems to me that a more robust solution for registering/unregistering these probes is necessary - one that tolerates the threads being in stopped or running or whatever state. Another problem: under some conditions, it seems we can have a race between uprobes and gdbstub w.r.t. the handling of the SSOL instructions. Sometimes by the time the gdbstub's uprobe-handler code is called, and some time later, gdb starts asking for register contents, the user-regset PC has been updated to point at the SSOL memory page. GDB can't make heads or tails of that. I don't know if this is a symptom of a deeper utrace issue. I pushed my current version of utrace-gdbstub-uprobes for your joint pain-sharing. - FChE
