[binutils-gdb] PPC64: Fix step-over-trips-on-watchpoint.exp with displaced stepping on

[sergiodj+buildbot at redhat dot com]

*** TEST RESULTS FOR COMMIT cb71640d030500888726d54a310c434a4d23b7b3 ***

Author: Pedro Alves <palves@redhat.com>
Branch: master
Commit: cb71640d030500888726d54a310c434a4d23b7b3

PPC64: Fix step-over-trips-on-watchpoint.exp with displaced stepping on
PPC64 currently fails this test like:

 FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: no thread-specific bp: step: step
 FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: no thread-specific bp: next: next
 FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: no thread-specific bp: continue: continue (the program exited)
 FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: step: step
 FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: next: next
 FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: continue: continue (the program exited)

The problem is that PPC is a non-continuable watchpoints architecture
and the displaced stepping code isn't coping with that correctly.  On
such targets/architectures, a watchpoint traps _before_ the
instruction executes/completes.  On a watchpoint trap, the PC points
at the instruction that triggers the watchpoint (side effects haven't
happened yet).  In order to move past the watchpoint, GDB needs to
remove the watchpoint, single-step, and reinsert the watchpoint, just
like when stepping past a breakpoint.

The trouble is that if GDB is stepping over a breakpoint with
displaced stepping, and the instruction under the breakpoint triggers
a watchpoint, we get the watchpoint SIGTRAP, expecting a finished
(hard or software) step trap.  Even though the thread's PC hasn't
advanced yet (must remove watchpoint for that), since we get a
SIGTRAP, displaced_step_fixup thinks the single-step finished
successfuly anyway, and calls gdbarch_displaced_step_fixup, which then
adjusts the thread's registers incorrectly.

The fix is to cancel the displaced step if we trip on a watchpoint.
handle_inferior_event then processes the watchpoint event, and starts
a new step-over, here:

...
      /* At this point, we are stopped at an instruction which has
         attempted to write to a piece of memory under control of
         a watchpoint.  The instruction hasn't actually executed
         yet.  If we were to evaluate the watchpoint expression
         now, we would get the old value, and therefore no change
         would seem to have occurred.
...
      ecs->event_thread->stepping_over_watchpoint = 1;
      keep_going (ecs);
      return;
...

but this time, since we have a watchpoint to step over, watchpoints
are removed from the target, so the step-over succeeds.

The keep_going/resume changes are necessary because if we're stepping
over a watchpoint, we need to remove it from the target - displaced
stepping doesn't help, the copy of the instruction in the scratch pad
reads/writes to the same addresses, thus triggers the watchpoint
too...  So without those changes we keep triggering the watchpoint
forever, never making progress.  With non-stop that means we'll need
to pause all threads momentarily, which we can't today.  We could
avoid that by removing the watchpoint _only_ from the thread that is
moving past the watchpoint, but GDB is not prepared for that today
either.  For remote targets, that would need new packets, so good to
be able to step over it in-line as fallback anyway.

gdb/ChangeLog:
2015-04-10  Pedro Alves  <palves@redhat.com>

	* infrun.c (displaced_step_fixup): Switch to the event ptid
	earlier.  If the thread stopped for a watchpoint and the
	target/arch has non-continuable watchpoints, cancel the displaced
	step.
	(resume): Don't start a displaced step if in-line step-over info
	is valid.