Don't displaced step when there's a breakpoint in the scratch pad range

Assuming displaced stepping is enabled, and a breakpoint is set in the
memory region of the scratch pad, things break.  One of two cases can
happen:

#1 - The breakpoint wasn't inserted yet (all threads were stopped), so
     after setting up the displaced stepping scratch pad with the
     adjusted copy of the instruction we're trying to single-step, we
     insert the breakpoint, which corrupts the scratch pad, and the
     inferior executes the wrong instruction.  (Example below.)
     This is clearly unacceptable.

#2 - The breakpoint was already inserted, so setting up the displaced
     stepping scratch pad overwrites the breakpoint.  This is OK in
     the sense that we already assume that no thread is going to
     executes the code in the scratch pad range (after initial
     startup) anyway.

This commit addresses both cases by simply punting on displaced
stepping if we have a breakpoint in the scratch pad range.

The #1 case above explains a few regressions exposed by the AS/NS
series on x86:

 Running ./gdb.dwarf2/callframecfa.exp ...
 FAIL: gdb.dwarf2/callframecfa.exp: set display for call-frame-cfa
 FAIL: gdb.dwarf2/callframecfa.exp: step 1 for call-frame-cfa
 FAIL: gdb.dwarf2/callframecfa.exp: step 2 for call-frame-cfa
 FAIL: gdb.dwarf2/callframecfa.exp: step 3 for call-frame-cfa
 FAIL: gdb.dwarf2/callframecfa.exp: step 4 for call-frame-cfa
 Running ./gdb.dwarf2/typeddwarf.exp ...
 FAIL: gdb.dwarf2/typeddwarf.exp: continue to breakpoint: continue to typeddwarf.c:53
 FAIL: gdb.dwarf2/typeddwarf.exp: check value of x at typeddwarf.c:53
 FAIL: gdb.dwarf2/typeddwarf.exp: check value of y at typeddwarf.c:53
 FAIL: gdb.dwarf2/typeddwarf.exp: check value of z at typeddwarf.c:53
 FAIL: gdb.dwarf2/typeddwarf.exp: continue to breakpoint: continue to typeddwarf.c:73
 FAIL: gdb.dwarf2/typeddwarf.exp: check value of w at typeddwarf.c:73
 FAIL: gdb.dwarf2/typeddwarf.exp: check value of x at typeddwarf.c:73
 FAIL: gdb.dwarf2/typeddwarf.exp: check value of y at typeddwarf.c:73
 FAIL: gdb.dwarf2/typeddwarf.exp: check value of z at typeddwarf.c:73

Enabling "maint set target-non-stop on" implies displaced stepping
enabled as well, and it's the latter that's to blame here.  We can see
the same failures with "maint set target-non-stop off + set displaced
on".

Diffing (good/bad) gdb.log for callframecfa.exp shows:

 @@ -99,29 +99,29 @@ Breakpoint 2 at 0x80481b0: file q.c, lin
  continue
  Continuing.

 -Breakpoint 2, func (arg=77) at q.c:2
 +Breakpoint 2, func (arg=52301) at q.c:2
  2      in q.c
  (gdb) PASS: gdb.dwarf2/callframecfa.exp: continue to breakpoint: continue to breakpoint for call-frame-cfa
  display arg
 -1: arg = 77
 -(gdb) PASS: gdb.dwarf2/callframecfa.exp: set display for call-frame-cfa
 +1: arg = 52301
 +(gdb) FAIL: gdb.dwarf2/callframecfa.exp: set display for call-frame-cfa

The problem is here, when setting up the func call:

 Breakpoint 1, main (argc=-13345, argv=0x0) at q.c:7
 7       in q.c

 (gdb) disassemble
 Dump of assembler code for function main:
    0x080481bb <+0>:     push   %ebp
    0x080481bc <+1>:     mov    %esp,%ebp
    0x080481be <+3>:     sub    $0x4,%esp
 => 0x080481c1 <+6>:     movl   $0x4d,(%esp)
    0x080481c8 <+13>:    call   0x80481b0 <func>
    0x080481cd <+18>:    leave
    0x080481ce <+19>:    ret
 End of assembler dump.
 (gdb) disassemble /r
 Dump of assembler code for function main:
    0x080481bb <+0>:     55      push   %ebp
    0x080481bc <+1>:     89 e5   mov    %esp,%ebp
    0x080481be <+3>:     83 ec 04        sub    $0x4,%esp
 => 0x080481c1 <+6>:     c7 04 24 4d 00 00 00    movl   $0x4d,(%esp)
    0x080481c8 <+13>:    e8 e3 ff ff ff  call   0x80481b0 <func>
    0x080481cd <+18>:    c9      leave
    0x080481ce <+19>:    c3      ret
 End of assembler dump.

Note the breakpoint at main is set at 0x080481c1.  Right at the
instruction that sets up func's argument.  Executing that instruction
should write 0x4d to the address pointed at by $esp.  However, if we
stepi, the program manages to write 52301/0xcc4d there instead (0xcc
is int3, the x86 breakpoint instruction), because the breakpoint
address is 4 bytes inside the scratch pad location, which is
0x080481bd:

 (gdb) p 0x080481c1 - 0x080481bd
 $1 = 4

IOW, instead of executing:

  "c7 04 24 4d 00 00 00" [ movl $0x4d,(%esp) ]

the inferior executes:

  "c7 04 24 4d cc 00 00" [ movl $0xcc4d,(%esp) ]

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

	* breakpoint.c (breakpoint_in_range_p)
	(breakpoint_location_address_range_overlap): New functions.
	* breakpoint.h (breakpoint_in_range_p): New declaration.
	* infrun.c (displaced_step_prepare_throw): If there's a breakpoint
	in the scratch pad range, don't displaced step.

1 files changed, 5 insertions, 0 deletions

diff --git a/gdb/breakpoint.h b/gdb/breakpoint.h
index 896d3eb..ee8b2e0 100644
--- a/gdb/breakpoint.h
+++ b/gdb/breakpoint.h
@@ -1146,6 +1146,11 @@ extern int program_breakpoint_here_p (struct gdbarch *gdbarch, CORE_ADDR address
 extern enum breakpoint_here breakpoint_here_p (struct address_space *, 
 					       CORE_ADDR);
 
+/* Return true if an enabled breakpoint exists in the range defined by
+   ADDR and LEN, in ASPACE.  */
+extern int breakpoint_in_range_p (struct address_space *aspace,
+				  CORE_ADDR addr, ULONGEST len);
+
 extern int moribund_breakpoint_here_p (struct address_space *, CORE_ADDR);
 
 extern int breakpoint_inserted_here_p (struct address_space *, CORE_ADDR);