mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-11-25 19:14:52 +08:00
6e41445bb0
When running test-case gdb.base/longjmp.exp on x86_64-linux, the master longjmp breakpoint is set using probes and the test-case passes: ... (gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1) next^M 0x00000000004005cc 49 if (setjmp (env) == 0) /* patt1 */^M (gdb) PASS: gdb.base/longjmp.exp: next over longjmp(1) next^M 56 resumes++;^M (gdb) PASS: gdb.base/longjmp.exp: next into else block (1) ... However, if I disable create_longjmp_master_breakpoint_probe, we have instead: ... (gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1) next^M 56 resumes++;^M (gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1) ... At first glance, the failure mode doesn't look too bad: we stop a few insns later than the passing scenario. For contrast, if we do the same on powerpc64le, the failure mode is: ... (gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1) next^M ^M Breakpoint 3, main () at longjmp.c:59^M 59 i = 1; /* miss_step_1 */^M (gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1) ... Here we only stop because of running into the safety net breakpoint at miss_step_1. So, how does this happen on x86_64? Let's look at the code: ... 4005c7: e8 94 fe ff ff call 400460 <_setjmp@plt> 4005cc: 85 c0 test %eax,%eax 4005ce: 75 1e jne 4005ee <main+0x3b> 4005d0: 8b 05 8e 0a 20 00 mov 0x200a8e(%rip),%eax # 601064 <longjmps> 4005d6: 83 c0 01 add $0x1,%eax 4005d9: 89 05 85 0a 20 00 mov %eax,0x200a85(%rip) # 601064 <longjmps> 4005df: be 01 00 00 00 mov $0x1,%esi 4005e4: bf 80 10 60 00 mov $0x601080,%edi 4005e9: e8 82 fe ff ff call 400470 <longjmp@plt> 4005ee: 8b 05 74 0a 20 00 mov 0x200a74(%rip),%eax # 601068 <resumes> ... The next over the longjmp call at 4005e9 is supposed to stop at the longjmp target at 4005cc, but instead we stop at 4005ee, where we have the step-resume breakpoint inserted by the next. In other words, we accidentally "return" from the longjmp call to the insn immediately after it (even though a longjmp is a noreturn function). Try to avoid this accident and make the failure mode on x86_64 the same as on powerpc64le, by switching the then and else branch. Tested on x86_64-linux. |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
contrib | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gdbserver | ||
gdbsupport | ||
gnulib | ||
gold | ||
gprof | ||
gprofng | ||
include | ||
intl | ||
ld | ||
libbacktrace | ||
libctf | ||
libdecnumber | ||
libiberty | ||
libsframe | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
ar-lib | ||
ChangeLog | ||
compile | ||
config-ml.in | ||
config.guess | ||
config.rpath | ||
config.sub | ||
configure | ||
configure.ac | ||
COPYING | ||
COPYING3 | ||
COPYING3.LIB | ||
COPYING.LIB | ||
COPYING.LIBGLOSS | ||
COPYING.NEWLIB | ||
depcomp | ||
djunpack.bat | ||
install-sh | ||
libtool.m4 | ||
lt~obsolete.m4 | ||
ltgcc.m4 | ||
ltmain.sh | ||
ltoptions.m4 | ||
ltsugar.m4 | ||
ltversion.m4 | ||
MAINTAINERS | ||
Makefile.def | ||
Makefile.in | ||
Makefile.tpl | ||
makefile.vms | ||
missing | ||
mkdep | ||
mkinstalldirs | ||
move-if-change | ||
multilib.am | ||
README | ||
README-maintainer-mode | ||
setup.com | ||
src-release.sh | ||
symlink-tree | ||
test-driver | ||
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.