What matters for this function, is whether the user requested a
"step", for "set scheduler-locking step", not whether GDB is doing an
internal step for some reason.
/* Return a ptid representing the set of threads that we will proceed,
in the perspective of the user/frontend. */
extern ptid_t user_visible_resume_ptid (int step);
Therefore, the check for singlestep_breakpoints_inserted_p is actually
incorrect, and we end up applying schedlock more often on sss targets
than on non-sss targets.
Found by inspection while working on a patch that eliminates the
singlestep_breakpoints_inserted_p global.
Tested on x86_64 Fedora 20 on top of my 'software single-step on x86'
series.
gdb/
2014-09-25 Pedro Alves <palves@redhat.com>
* infrun.c (user_visible_resume_ptid): Don't check
singlestep_breakpoints_inserted_p.
+2014-09-25 Pedro Alves <palves@redhat.com>
+
+ * infrun.c (user_visible_resume_ptid): Don't check
+ singlestep_breakpoints_inserted_p.
+
2014-09-25 Pedro Alves <palves@redhat.com>
* breakpoint.c (should_be_inserted): Add debug output.
resume_ptid = inferior_ptid;
}
else if ((scheduler_mode == schedlock_on)
- || (scheduler_mode == schedlock_step
- && (step || singlestep_breakpoints_inserted_p)))
+ || (scheduler_mode == schedlock_step && step))
{
/* User-settable 'scheduler' mode requires solo thread resume. */
resume_ptid = inferior_ptid;