summaryrefslogtreecommitdiff
path: root/gdb/breakpoint.h
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2015-10-30 16:00:43 +0000
committerPedro Alves <palves@redhat.com>2015-10-30 16:00:43 +0000
commitd35ae83384324ec7a03a56600174b5e925510b74 (patch)
tree6e5f9330bb0c150341e8282513f280b5b3e47add /gdb/breakpoint.h
parent4081c0f1222810746068579c6fbbcd8a9b59cbb8 (diff)
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.
Diffstat (limited to 'gdb/breakpoint.h')
-rw-r--r--gdb/breakpoint.h5
1 files changed, 5 insertions, 0 deletions
diff --git a/gdb/breakpoint.h b/gdb/breakpoint.h
index 896d3ebb42..ee8b2e0827 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);