infrun.c:user_visible_resume_ptid: Don't check singlestep_breakpoints_inserted_p

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.
This commit is contained in:
Pedro Alves 2014-09-22 11:12:30 +01:00
parent e558d7c109
commit 03d4695724
2 changed files with 6 additions and 2 deletions

View File

@ -1,3 +1,8 @@
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.

View File

@ -1739,8 +1739,7 @@ user_visible_resume_ptid (int step)
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;