No description
d35ae83384
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. |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gold | ||
gprof | ||
include | ||
intl | ||
ld | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.gitattributes | ||
.gitignore | ||
ChangeLog | ||
compile | ||
config-ml.in | ||
config.guess | ||
config.rpath | ||
config.sub | ||
configure | ||
configure.ac | ||
COPYING | ||
COPYING.LIB | ||
COPYING.LIBGLOSS | ||
COPYING.NEWLIB | ||
COPYING3 | ||
COPYING3.LIB | ||
depcomp | ||
djunpack.bat | ||
install-sh | ||
libtool.m4 | ||
ltgcc.m4 | ||
ltmain.sh | ||
ltoptions.m4 | ||
ltsugar.m4 | ||
ltversion.m4 | ||
lt~obsolete.m4 | ||
MAINTAINERS | ||
Makefile.def | ||
Makefile.in | ||
Makefile.tpl | ||
makefile.vms | ||
missing | ||
mkdep | ||
mkinstalldirs | ||
move-if-change | ||
README | ||
README-maintainer-mode | ||
setup.com | ||
src-release.sh | ||
symlink-tree | ||
ylwrap |
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.