mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-01-12 12:16:04 +08:00
16b10d6e61
New in v3: - Verify if the syscall number matches what is expected for the target. - Used gdb_assert for one more check. New in v2: - Set initial values to -1 instead of 0. - Rewrote RE to prevent unexpected matching when parsing one character at a time. - Used gdb_assert for an additional check. - Validated with check-read1 There are a couple problems with this test. First -- gdb.base/step-over-syscall.exp records the address of a syscall instruction within fork/vfork/clone functions and also the address of the instruction after that syscall instruction. It uses these couples addresses to make sure we stepped over a syscall instruction (fork/vfork/clone events) correctly. The way the test fetches the addresses of the instructions is by stepi-ing its way through the fork/vfork/clone functions until it finds a match for a syscall. Then it stepi's once again to get the address of the next instruction. This assumes that stepi-ing over a syscall is working correctly and landing in the right PC. This is not the case for AArch64/Linux, where we're landing a couple instructions after the syscall in some cases. The following patch lets the test execute as before, but adds a new instruction address check using the x command as opposed to stepi. I didn't want to change how the test works since we may also be interested in checking if stepi-ing over the syscall under different conditions (displaced stepping on/off) yields the same results. I don't feel strongly about this, so i'm OK with changing how we compare PC's for the entire test if folks decide it is reasonable. Second -- FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: continue to vfork (3rd time) (the program exited) FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: continue to syscall insn vfork (the program is no longer running) FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: single step over vfork (the program is no longer running) Depending on the glibc version we may have different code generated for the fork/vfork/clone functions. I ran into the situation where vfork for newer glibc's on AArch64/Linux is very short, so "break vfork" will put a breakpoint right at the syscall instruction, which is something the testcase isn't expecting (a off-by-1 of sorts). The patch adds extra code to handle this case. If the test detects we're already sitting at a syscall instruction, it records the address and moves on to record the address after that particular instruction. Another measure is to "break *$syscall" instead of "break $syscall". That guarantees we're stopping at the first instruction of the syscall function, if it ever happens that the syscall instruction is the first instruction of those functions. With these changes i can fix some failures for aarch64-linux-gnu and also expose the problems i've reported here: https://sourceware.org/ml/gdb-patches/2019-12/msg01071.html These tests now fail for aarch64-linux-gnu (patch for this is going through reviews): FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: pc after stepi matches insn addr after syscall FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=on: pc after stepi matches insn addr after syscall gdb/testsuite/ChangeLog: 2020-01-27 Luis Machado <luis.machado@linaro.org> * gdb.base/step-over-syscall.exp (setup): Check if we're already sitting at a syscall instruction when we hit the syscall function's breakpoint. Check PC against one obtained with the x command. Validate syscall number. (step_over_syscall): Don't continue to the syscall instruction if we're already there. |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
contrib | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gdbsupport | ||
gnulib | ||
gold | ||
gprof | ||
include | ||
intl | ||
ld | ||
libctf | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.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.