mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-03-07 13:39:43 +08:00
Fedora GDB has, for years, carried an out of tree patch for the gdb.base/annota{1,3}.exp tests. The patch simply adds a call to 'set breakpoint pending off' near the start of each test. Normally GDB tests are written using gdb_test or gdb_test_multiple, with gdb_test being a wrapper around gdb_test_multiple. Inside gdb_test_multiple we add a test pattern which detects if GDB offers the user an interactive yes/no prompt and immediately fails the test. What this means is that if something goes wrong with a test like: gdb_test "break main" ".*" and GDB ends up offering this prompt: Make breakpoint pending on future shared library load? (y or [n]) then instead of hanging waiting for the test to timeout, DejaGNU will spot the interactive prompt and immediately fail the test. In the gdb.base/annota{1,3}.exp tests we turn on GDB's annotation mode, and many of the tests in these scripts are written using send_gdb and gdb_expect or gdb_expect_list. This is done because in the past, gdb_test_multiple and friends were hard-coded to use the "normal" GDB prompt, and these tests instead expect the annotated prompt. Specifically, gdb_test_multiple expects '$gdb_prompt $' as the full prompt, that is the value of $gdb_prompt followed by a single white space. The annotation tests do update the value of $gdb_prompt, but with annotations on there is no trailing whitespace, so gdb_test_multiple's default behaviour doesn't work, which is why the test scripts originally avoided using gdb_test_multiple. As a result none of the tests in these files would early exit if we got an interactive yes/no prompt, and instead we'd be relying on each test to timeout, which could take a while. However, gdb_test_multiple now accepts a -prompt argument, so we can modify the prompt we are looking for, which is neat. So, I started off by going through these tests an changing all of the tests that create a breakpoint to use gdb_test, passing the -prompt option to change the prompt. While doing that I noticed some other things that I could improve in these tests, I've cleaned up the use of standard_testfile, switched to use prepare_for_testing, and removed some redundant clean_restart and 'set height 0' calls (set height 0 is done within clean_restart, which is called by prepare_for_testing). I've updated some comments which said "we can't use gdb_test" to say "we can use gdb_test with -prompt option", and I've removed some commented out debug code (e.g. setting 'exp_internal'). Finally, I ran these two tests through check-all-boards, and spotted that annota1.exp failed when using a remote host. This is because one test checks for a full path to the binary in some output, and with a remote host the binary ends up being copied and the path is not as expected. I'm assuming that checking the full path is important, so I've disabled this test on remote host boards. After all these changes I checked using 'make check-all-boards' and there are no unexpected results on either of these tests. Tested-By: Tom de Vries <tdevries@suse.de> Acked-By: Tom de Vries <tdevries@suse.de> |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
contrib | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gdbserver | ||
gdbsupport | ||
gnulib | ||
gold | ||
gprof | ||
gprofng | ||
include | ||
ld | ||
libbacktrace | ||
libctf | ||
libdecnumber | ||
libiberty | ||
libsframe | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
.pre-commit-config.yaml | ||
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 | ||
SECURITY.txt | ||
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.