Misc switch_back_to_stepped_thread cleanups
authorPedro Alves <palves@redhat.com>
Fri, 7 Aug 2015 16:23:58 +0000 (17:23 +0100)
committerPedro Alves <palves@redhat.com>
Fri, 7 Aug 2015 16:23:58 +0000 (17:23 +0100)
commit1afd5965eda86caed3af7f23fd1f8802831360b6
tree2b906f2100e28f060b1f75f3880e42230de59c06
parent4d9d9d0423ed611fa6d620ca3aa088fc16a0d59e
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.
gdb/ChangeLog
gdb/infrun.c