aboutsummaryrefslogtreecommitdiff
path: root/gdb/source.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2015-08-07 17:23:58 +0100
committerPedro Alves <palves@redhat.com>2015-08-07 17:23:58 +0100
commit1afd5965eda86caed3af7f23fd1f8802831360b6 (patch)
tree2b906f2100e28f060b1f75f3880e42230de59c06 /gdb/source.c
parent4d9d9d0423ed611fa6d620ca3aa088fc16a0d59e (diff)
downloadgdb-1afd5965eda86caed3af7f23fd1f8802831360b6.zip
gdb-1afd5965eda86caed3af7f23fd1f8802831360b6.tar.gz
gdb-1afd5965eda86caed3af7f23fd1f8802831360b6.tar.bz2
Misc switch_back_to_stepped_thread cleanups
Several misc cleanups that prepare the tail end of this function, the part that actually re-resumes the stepped thread. The most non-obvious would be the currently_stepping change, I guess. That's because it isn't ever correct to pass step=1 to target_resume on software single-step targets, and currently_stepping works at a conceptual higher level, it returns step=true even on software step targets. It doesn't really matter on hardware step targets, as the breakpoint will be hit immediately, but it's just wrong on software step targets. I tested it against my x86 software single-step branch, and it indeed fixes failed assertions (that catch spurious PTRACE_SINGLESTEP requests) there. gdb/ChangeLog: 2015-08-07 Pedro Alves <palves@redhat.com> * infrun.c (switch_back_to_stepped_thread): Use ecs->ptid instead of inferior_ptid. If the stepped thread vanished, return 0 instead of resuming here. Use reset_ecs. Print the prev_pc and the current stop_pc in log message. Clear trap_expected if the thread advanced. Don't pass currently_stepping to do_target_resume.
Diffstat (limited to 'gdb/source.c')
0 files changed, 0 insertions, 0 deletions