diff options
| author | Pedro Alves <palves@redhat.com> | 2014-09-22 11:12:30 +0100 |
|---|---|---|
| committer | Pedro Alves <palves@redhat.com> | 2014-09-25 16:56:00 +0100 |
| commit | 03d469572472d5c59d8a35030bb1b8072c217dc7 (patch) | |
| tree | d19dbac24676f42221856770492eb21cd959f389 /gold | |
| parent | e558d7c1095545832a90e76f72e6db6c98fdee0f (diff) | |
| download | gdb-03d469572472d5c59d8a35030bb1b8072c217dc7.zip gdb-03d469572472d5c59d8a35030bb1b8072c217dc7.tar.gz gdb-03d469572472d5c59d8a35030bb1b8072c217dc7.tar.bz2 | |
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.
Diffstat (limited to 'gold')
0 files changed, 0 insertions, 0 deletions