binutils-gdb/gdb/testsuite/Makefile.in

378 lines
13 KiB
Makefile
Raw Normal View History

# Makefile for regression testing the GNU debugger.
# Copyright 1992-2017 Free Software Foundation, Inc.
# This file is part of GDB.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
VPATH = @srcdir@
srcdir = @srcdir@
prefix = @prefix@
exec_prefix = @exec_prefix@
abs_builddir = @abs_builddir@
Fix in-tree, parallel running of Ada tests While testing the following patch, [PATCH] Always organize test artifacts in a directory hierarchy https://sourceware.org/ml/gdb-patches/2016-01/msg00133.html I noticed that it broke Ada testing. This lead me to think that parallel testing when building in-tree didn't work previously in Ada. It is confirmed by this test: $ make check TESTS="gdb.ada/fun_addr.exp" -j 2 ... Running ./gdb.ada/fun_addr.exp ... FAIL: gdb.ada/fun_addr.exp: compilation foo.adb ... This patch fixes in-tree parallel testing for Ada, and consequently serial and parallel testing when the aforementioned patch is applied. The problem originates from the fact that Ada support code cd's to the builddir before compiling. In itself it's not a problem, it allows to place intermediate auto-generated files in that directory. The Ada compilation refers to the source file, which is in another directory, only by its base name (e.g. foo.adb). In serial mode, that worked because builddir was the same as the source directory (e.g. gdb.ada/fun_addr/). In an out-of-tree build, it works because the source directory is added as an include directory (note: this is not the same $srcdir as autoconf's): set srcdir [file dirname $source] additional_flags=-I$srcdir which becomes: additional_flags=-I/home/emaisin/build/binutils-gdb/gdb/testsuite/gdb.ada/fun_addr However, when building in-tree, srcdir is relative: ./gdb.ada/fun_addr. When using parallel or always-in-outputs-directory mode, we are cd'ed in the outputs directory. So -I$srcdir is relative to the current directory, which is wrong. To fix it, I made the TCL variable srcdir (set in site.exp, from which everything else is derived) always absolute. It is done by assigning autoconf's abs_srcdir instead of autoconf's srcdir. This way -I$srcdir will always be good, regardless of where we cd'ed to. A small apparent change is that when running tests, DejaGnu will say: Running /tmp/binutils-gdb/gdb/testsuite/gdb.ada/fun_addr.exp ... instead of Running ./gdb.ada/fun_addr.exp ... I hope it's not too much of an annoyance. I think that it should make the testsuite a tiny bit more robust against other bugs of the same class. Regtested in & out of tree, only with native target. gdb/testsuite/ChangeLog: * Makefile.in (abs_srcdir): Assign @abs_srcdir@. (site.exp): Assign abs_srcdir to tcl's srcdir.
2016-02-08 20:00:49 +01:00
abs_srcdir = @abs_srcdir@
target_alias = @target_noncanonical@
program_transform_name = @program_transform_name@
build_canonical = @build@
host_canonical = @host@
target_canonical = @target@
SHELL = @SHELL@
EXEEXT = @EXEEXT@
SUBDIRS = @subdirs@
RPATH_ENVVAR = @RPATH_ENVVAR@
EXTRA_RULES = @EXTRA_RULES@
CC=@CC@
EXPECT = `if [ "$${READ1}" != "" ] ; then \
echo $${rootme}/expect-read1; \
elif [ -f $${rootme}/../../expect/expect ] ; then \
echo $${rootme}/../../expect/expect ; \
else \
echo expect ; \
fi`
RUNTEST = $(RUNTEST_FOR_TARGET)
RUNTESTFLAGS =
FORCE_PARALLEL =
Improve analysis of racy testcases This is an initial attempt to introduce some mechanisms to identify racy testcases present in our testsuite. As can be seen in previous discussions, racy tests are really bothersome and cause our BuildBot to pollute the gdb-testers mailing list with hundreds of false-positives messages every month. Hopefully, identifying these racy tests in advance (and automatically) will contribute to the reduction of noise traffic to gdb-testers, maybe to the point where we will be able to send the failure messages directly to the authors of the commits. I spent some time trying to decide the best way to tackle this problem, and decided that there is no silver bullet. Racy tests are tricky and it is difficult to catch them, so the best solution I could find (for now?) is to run our testsuite a number of times in a row, and then compare the results (i.e., the gdb.sum files generated during each run). The more times you run the tests, the more racy tests you are likely to detect (at the expense of waiting longer and longer). You can also run the tests in parallel, which makes things faster (and contribute to catching more racy tests, because your machine will have less resources for each test and some of them are likely to fail when this happens). I did some tests in my machine (8-core i7, 16GB RAM), and running the whole GDB testsuite 5 times using -j6 took 23 minutes. Not bad. In order to run the racy test machinery, you need to specify the RACY_ITER environment variable. You will assign a number to this variable, which represents the number of times you want to run the tests. So, for example, if you want to run the whole testsuite 3 times in parallel (using 2 cores), you will do: make check RACY_ITER=3 -j2 It is also possible to use the TESTS variable and specify which tests you want to run: make check TEST='gdb.base/default.exp' RACY_ITER=3 -j2 And so on. The output files will be put at the directory gdb/testsuite/racy_outputs/. After make invokes the necessary rules to run the tests, it finally runs a Python script that will analyze the resulting gdb.sum files. This Python script will read each file, and construct a series of sets based on the results of the tests (one set for FAIL's, one for PASS'es, one for KFAIL's, etc.). It will then do some set operations and come up with a list of unique, sorted testcases that are racy. The algorithm behind this is: for state in PASS, FAIL, XFAIL, XPASS...; do if a test's state in every sumfile is $state; then it is not racy else it is racy (The algorithm is actually a bit more complex than that, because it takes into account other things in order to decide whether the test should be ignored or not). IOW, a test must have the same state in every sumfile. After processing everything, the script prints the racy tests it could identify on stdout. I am redirecting this to a file named racy.sum. Something else that I wasn't sure how to deal with was non-unique messages in our testsuite. I decided to do the same thing I do in our BuildBot: include a unique identifier in the end of message, like: gdb.base/xyz.exp: non-unique message gdb.base/xyz.exp: non-unique message <<2>> This means that you will have to be careful about them when you use the racy.sum file. I ran the script several times here, and it did a good job catching some well-known racy tests. Overall, I am satisfied with this approach and I think it will be helpful to have it upstream'ed. I also intend to extend our BuildBot and create new, specialized builders that will be responsible for detecting the racy tests every X number of days. 2016-03-05 Sergio Durigan Junior <sergiodj@redhat.com> * Makefile.in (DEFAULT_RACY_ITER): New variable. (CHECK_TARGET_TMP): Likewise. (check-single-racy): New rule. (check-parallel-racy): Likewise. (TEST_TARGETS): Adjust rule to account for RACY_ITER. (do-check-parallel-racy): New rule. (check-racy/%.exp): Likewise. * README (Racy testcases): New section. * analyze-racy-logs.py: New file.
2016-03-06 02:37:11 +01:00
# Default number of iterations that we will use to run the testsuite
# if the user does not specify the RACY_ITER environment variable
# (e.g., when the user calls the make rule directly from the command
# line).
DEFAULT_RACY_ITER = 3
RUNTEST_FOR_TARGET = `\
if [ -f $${srcdir}/../../dejagnu/runtest ]; then \
echo $${srcdir}/../../dejagnu/runtest; \
else \
if [ "$(host_canonical)" = "$(target_canonical)" ]; then \
echo runtest; \
else \
t='$(program_transform_name)'; echo runtest | sed -e $$t; \
fi; \
fi`
#### host, target, and site specific Makefile frags come in here.
# The use of $$(x_FOR_TARGET) reduces the command line length by not
# duplicating the lengthy definition.
TARGET_FLAGS_TO_PASS = \
"prefix=$(prefix)" \
"exec_prefix=$(exec_prefix)" \
"against=$(against)" \
'CC=$$(CC_FOR_TARGET)' \
"CC_FOR_TARGET=$(CC_FOR_TARGET)" \
"CFLAGS=$(TESTSUITE_CFLAGS)" \
'CXX=$$(CXX_FOR_TARGET)' \
"CXX_FOR_TARGET=$(CXX_FOR_TARGET)" \
"CXXFLAGS=$(CXXFLAGS)" \
"MAKEINFO=$(MAKEINFO)" \
"INSTALL=$(INSTALL)" \
"INSTALL_PROGRAM=$(INSTALL_PROGRAM)" \
"INSTALL_DATA=$(INSTALL_DATA)" \
"LDFLAGS=$(LDFLAGS)" \
"LIBS=$(LIBS)" \
"RUNTEST=$(RUNTEST)" \
"RUNTESTFLAGS=$(RUNTESTFLAGS)"
all: $(EXTRA_RULES)
@echo "Nothing to be done for all..."
.NOEXPORT:
INFODIRS=doc
info:
install-info:
dvi:
pdf:
install-pdf:
1999-06-28 18:06:02 +02:00
html:
install-html:
install:
uninstall: force
# Use absolute `site.exp' path everywhere to suppress VPATH lookups for it.
# Bare `site.exp' is used as a target here if user requests it explicitly.
# $(RUNTEST) is looking up `site.exp' only in the current directory.
$(abs_builddir)/site.exp site.exp: ./config.status Makefile
@echo "Making a new config file..."
-@rm -f ./tmp?
@touch site.exp
-@mv site.exp site.bak
@echo "## these variables are automatically generated by make ##" > ./tmp0
@echo "# Do not edit here. If you wish to override these values" >> ./tmp0
@echo "# add them to the last section" >> ./tmp0
@echo "set host_triplet ${host_canonical}" >> ./tmp0
@echo "set target_alias $(target_alias)" >> ./tmp0
@echo "set target_triplet ${target_canonical}" >> ./tmp0
@echo "set build_triplet ${build_canonical}" >> ./tmp0
Fix in-tree, parallel running of Ada tests While testing the following patch, [PATCH] Always organize test artifacts in a directory hierarchy https://sourceware.org/ml/gdb-patches/2016-01/msg00133.html I noticed that it broke Ada testing. This lead me to think that parallel testing when building in-tree didn't work previously in Ada. It is confirmed by this test: $ make check TESTS="gdb.ada/fun_addr.exp" -j 2 ... Running ./gdb.ada/fun_addr.exp ... FAIL: gdb.ada/fun_addr.exp: compilation foo.adb ... This patch fixes in-tree parallel testing for Ada, and consequently serial and parallel testing when the aforementioned patch is applied. The problem originates from the fact that Ada support code cd's to the builddir before compiling. In itself it's not a problem, it allows to place intermediate auto-generated files in that directory. The Ada compilation refers to the source file, which is in another directory, only by its base name (e.g. foo.adb). In serial mode, that worked because builddir was the same as the source directory (e.g. gdb.ada/fun_addr/). In an out-of-tree build, it works because the source directory is added as an include directory (note: this is not the same $srcdir as autoconf's): set srcdir [file dirname $source] additional_flags=-I$srcdir which becomes: additional_flags=-I/home/emaisin/build/binutils-gdb/gdb/testsuite/gdb.ada/fun_addr However, when building in-tree, srcdir is relative: ./gdb.ada/fun_addr. When using parallel or always-in-outputs-directory mode, we are cd'ed in the outputs directory. So -I$srcdir is relative to the current directory, which is wrong. To fix it, I made the TCL variable srcdir (set in site.exp, from which everything else is derived) always absolute. It is done by assigning autoconf's abs_srcdir instead of autoconf's srcdir. This way -I$srcdir will always be good, regardless of where we cd'ed to. A small apparent change is that when running tests, DejaGnu will say: Running /tmp/binutils-gdb/gdb/testsuite/gdb.ada/fun_addr.exp ... instead of Running ./gdb.ada/fun_addr.exp ... I hope it's not too much of an annoyance. I think that it should make the testsuite a tiny bit more robust against other bugs of the same class. Regtested in & out of tree, only with native target. gdb/testsuite/ChangeLog: * Makefile.in (abs_srcdir): Assign @abs_srcdir@. (site.exp): Assign abs_srcdir to tcl's srcdir.
2016-02-08 20:00:49 +01:00
@echo "set srcdir ${abs_srcdir}" >> ./tmp0
@echo "set tool gdb" >> ./tmp0
@echo 'source $${srcdir}/lib/append_gdb_boards_dir.exp' >> ./tmp0
@echo "## All variables above are generated by configure. Do Not Edit ##" >> ./tmp0
@cat ./tmp0 > site.exp
@cat site.bak | sed \
-e '1,/^## All variables above are.*##/ d' >> site.exp
-@rm -f ./tmp?
installcheck:
switch to fully parallel mode This switches "make check" to fully parallel mode. One primary issue facing full parallelization is the overhead of "runtest". On my machine, if I "touch gdb.base/empty.exp", making a new file, and then "time runtest.exp", it takes 0.08 seconds. Multiply this by the 1008 (in my configuration) tests and you get ~80 seconds. This is the overhead that would theoretically be present if all tests were run in parallel. However, the problem isn't nearly as bad as this, for two reasons. First, you must divide by the number of jobs, assuming perfect parallelization -- reasonably true for small -j numbers, based on the results I see. Second, the current test suite parallelization approach bundles the tests, largely by directory, but also splitting up gdb.base into two halves. I was curious to see how the current bundling played out in practice, so I ran "make -j1 check RUNTEST='/bin/time runtest'". This invokes the parallel mode (thus the bundling) and then shows the time taken by each invocation of runtest. Then, I ran "/bin/time make -j3 check". (See below about -j2.) The time for the entire -j3 test run was the same as the time for "gdb.base1". What this means is that gdb.base1 is currently the time-limiting run, preventing further parallelization gains. So, I reason, whatever overhead we see from full parallelization will only be seen by "-j1" and "-j2". I then tried a -j2 test run. This does take longer than a -j3 build, meaning that the gdb.base1 job finishes and then proceeds to other runtest invocations. Finally I tried a -j2 test run with the appended patch. This was 9% slower than the -j2 run without the patch. I think that is a reasonable slowdown for what is probably a rare case. I believe this patch will yield faster test results for all -j values greater than 2. For -j3 on my machine, the test suite is a few seconds faster; I didn't try any larger -j values. For -j1, I went ahead and changed the Makefile so that, if no -j option is given, then the "check-single" mode is used. You can still use "make -j1 check" to get single-job parallel-mode, though of course there's no good reason to do so. This change is likely to speed up the plain "make check" scenario a little as we will now bypass dg-extract-results.sh. One drawback of this change is that "make -jN check" is now much more verbose. I generally only look at the .sum and .log files, but perhaps this will bother some. Another interesting question is scalability of the result. The slowest test, which limits the scalability, took 80.78 seconds. The mean of the remaining tests is 1.08 seconds. (Note that this is just a rough estimate, since there are still outliers.) This means we can run 80.78 / 1.08 =~ 74 tests in the time available. And, in this data set (slightly older than the above, but materially the same) there were 948 tests. So, I think the current test suite should scale ok up to about -j12. We could improve this number if need be by breaking up the biggest tests. 2013-11-04 Tom Tromey <tromey@redhat.com> * Makefile.in (TEST_DIRS): Remove. (TEST_TARGETS, check-parallel): Rewrite. (check-gdb.%, BASE1_FILES, BASE2_FILES, check-gdb.base%) (subdir_do, subdirs): Remove. (do-check-parallel, check/%): New targets. (clean): Remove outputs, temp, and cache directories. (saw_dash_j): New variable. (CHECK_TARGET): Use it. (check): Depend on all, site.exp. Rewrite. (check-single): Remove dependencies. (slow_tests, all_tests, reordered_tests): New variables.
2013-08-27 19:52:25 +02:00
# See whether -j was given to make. Either it was given with no
# arguments, and appears as "j" in the first word, or it was given an
# argument and appears as "-j" in a separate word.
Remove code that checks for GNU/non-GNU make Since GNU make is now required to build GDB, we can remove everything that checks whether the current make implemention is the GNU one or not. I simply removed the @GMAKE_TRUE@ prefixes and removed the whole lines that were prefixed with @GMAKE_FALSE@. I removed the code in the configure scripts that set those variables. I also removed the following bits from the configure scripts: AC_CHECK_PROGS(MAKE, make): GNU make already defines a MAKE variable internally to be used when invoking Makefiles recursively. I don't see this variable being used anywhere else (in scripts for example), so I think it's safe for removal. AC_PROG_MAKE_SET: This macro defines a SET_MAKE output variable, which is meant to be used in Makefiles to define the MAKE variable when using an implementation of make that doesn't already define it. Since we are now requiring GNU make, we don't need it anymore. Plus, I don't see SET_MAKE being used anywhere, so I don't think it was actually doing anything... gdb/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/gdbserver/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/testsuite/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate.
2016-11-17 18:00:10 +01:00
saw_dash_j = $(or $(findstring j,$(firstword $(MAKEFLAGS))),$(filter -j,$(MAKEFLAGS)))
switch to fully parallel mode This switches "make check" to fully parallel mode. One primary issue facing full parallelization is the overhead of "runtest". On my machine, if I "touch gdb.base/empty.exp", making a new file, and then "time runtest.exp", it takes 0.08 seconds. Multiply this by the 1008 (in my configuration) tests and you get ~80 seconds. This is the overhead that would theoretically be present if all tests were run in parallel. However, the problem isn't nearly as bad as this, for two reasons. First, you must divide by the number of jobs, assuming perfect parallelization -- reasonably true for small -j numbers, based on the results I see. Second, the current test suite parallelization approach bundles the tests, largely by directory, but also splitting up gdb.base into two halves. I was curious to see how the current bundling played out in practice, so I ran "make -j1 check RUNTEST='/bin/time runtest'". This invokes the parallel mode (thus the bundling) and then shows the time taken by each invocation of runtest. Then, I ran "/bin/time make -j3 check". (See below about -j2.) The time for the entire -j3 test run was the same as the time for "gdb.base1". What this means is that gdb.base1 is currently the time-limiting run, preventing further parallelization gains. So, I reason, whatever overhead we see from full parallelization will only be seen by "-j1" and "-j2". I then tried a -j2 test run. This does take longer than a -j3 build, meaning that the gdb.base1 job finishes and then proceeds to other runtest invocations. Finally I tried a -j2 test run with the appended patch. This was 9% slower than the -j2 run without the patch. I think that is a reasonable slowdown for what is probably a rare case. I believe this patch will yield faster test results for all -j values greater than 2. For -j3 on my machine, the test suite is a few seconds faster; I didn't try any larger -j values. For -j1, I went ahead and changed the Makefile so that, if no -j option is given, then the "check-single" mode is used. You can still use "make -j1 check" to get single-job parallel-mode, though of course there's no good reason to do so. This change is likely to speed up the plain "make check" scenario a little as we will now bypass dg-extract-results.sh. One drawback of this change is that "make -jN check" is now much more verbose. I generally only look at the .sum and .log files, but perhaps this will bother some. Another interesting question is scalability of the result. The slowest test, which limits the scalability, took 80.78 seconds. The mean of the remaining tests is 1.08 seconds. (Note that this is just a rough estimate, since there are still outliers.) This means we can run 80.78 / 1.08 =~ 74 tests in the time available. And, in this data set (slightly older than the above, but materially the same) there were 948 tests. So, I think the current test suite should scale ok up to about -j12. We could improve this number if need be by breaking up the biggest tests. 2013-11-04 Tom Tromey <tromey@redhat.com> * Makefile.in (TEST_DIRS): Remove. (TEST_TARGETS, check-parallel): Rewrite. (check-gdb.%, BASE1_FILES, BASE2_FILES, check-gdb.base%) (subdir_do, subdirs): Remove. (do-check-parallel, check/%): New targets. (clean): Remove outputs, temp, and cache directories. (saw_dash_j): New variable. (CHECK_TARGET): Use it. (check): Depend on all, site.exp. Rewrite. (check-single): Remove dependencies. (slow_tests, all_tests, reordered_tests): New variables.
2013-08-27 19:52:25 +02:00
Remove code that checks for GNU/non-GNU make Since GNU make is now required to build GDB, we can remove everything that checks whether the current make implemention is the GNU one or not. I simply removed the @GMAKE_TRUE@ prefixes and removed the whole lines that were prefixed with @GMAKE_FALSE@. I removed the code in the configure scripts that set those variables. I also removed the following bits from the configure scripts: AC_CHECK_PROGS(MAKE, make): GNU make already defines a MAKE variable internally to be used when invoking Makefiles recursively. I don't see this variable being used anywhere else (in scripts for example), so I think it's safe for removal. AC_PROG_MAKE_SET: This macro defines a SET_MAKE output variable, which is meant to be used in Makefiles to define the MAKE variable when using an implementation of make that doesn't already define it. Since we are now requiring GNU make, we don't need it anymore. Plus, I don't see SET_MAKE being used anywhere, so I don't think it was actually doing anything... gdb/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/gdbserver/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/testsuite/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate.
2016-11-17 18:00:10 +01:00
# Try to run the tests in parallel if any -j option is given. If RUNTESTFLAGS
# is not empty, then by default the tests will be serialized. This can be
# overridden by setting FORCE_PARALLEL to any non-empty value.
CHECK_TARGET_TMP = $(if $(FORCE_PARALLEL),check-parallel,$(if $(RUNTESTFLAGS),check-single,$(if $(saw_dash_j),check-parallel,check-single)))
CHECK_TARGET = $(if $(RACY_ITER),$(addsuffix -racy,$(CHECK_TARGET_TMP)),$(CHECK_TARGET_TMP))
switch to fully parallel mode This switches "make check" to fully parallel mode. One primary issue facing full parallelization is the overhead of "runtest". On my machine, if I "touch gdb.base/empty.exp", making a new file, and then "time runtest.exp", it takes 0.08 seconds. Multiply this by the 1008 (in my configuration) tests and you get ~80 seconds. This is the overhead that would theoretically be present if all tests were run in parallel. However, the problem isn't nearly as bad as this, for two reasons. First, you must divide by the number of jobs, assuming perfect parallelization -- reasonably true for small -j numbers, based on the results I see. Second, the current test suite parallelization approach bundles the tests, largely by directory, but also splitting up gdb.base into two halves. I was curious to see how the current bundling played out in practice, so I ran "make -j1 check RUNTEST='/bin/time runtest'". This invokes the parallel mode (thus the bundling) and then shows the time taken by each invocation of runtest. Then, I ran "/bin/time make -j3 check". (See below about -j2.) The time for the entire -j3 test run was the same as the time for "gdb.base1". What this means is that gdb.base1 is currently the time-limiting run, preventing further parallelization gains. So, I reason, whatever overhead we see from full parallelization will only be seen by "-j1" and "-j2". I then tried a -j2 test run. This does take longer than a -j3 build, meaning that the gdb.base1 job finishes and then proceeds to other runtest invocations. Finally I tried a -j2 test run with the appended patch. This was 9% slower than the -j2 run without the patch. I think that is a reasonable slowdown for what is probably a rare case. I believe this patch will yield faster test results for all -j values greater than 2. For -j3 on my machine, the test suite is a few seconds faster; I didn't try any larger -j values. For -j1, I went ahead and changed the Makefile so that, if no -j option is given, then the "check-single" mode is used. You can still use "make -j1 check" to get single-job parallel-mode, though of course there's no good reason to do so. This change is likely to speed up the plain "make check" scenario a little as we will now bypass dg-extract-results.sh. One drawback of this change is that "make -jN check" is now much more verbose. I generally only look at the .sum and .log files, but perhaps this will bother some. Another interesting question is scalability of the result. The slowest test, which limits the scalability, took 80.78 seconds. The mean of the remaining tests is 1.08 seconds. (Note that this is just a rough estimate, since there are still outliers.) This means we can run 80.78 / 1.08 =~ 74 tests in the time available. And, in this data set (slightly older than the above, but materially the same) there were 948 tests. So, I think the current test suite should scale ok up to about -j12. We could improve this number if need be by breaking up the biggest tests. 2013-11-04 Tom Tromey <tromey@redhat.com> * Makefile.in (TEST_DIRS): Remove. (TEST_TARGETS, check-parallel): Rewrite. (check-gdb.%, BASE1_FILES, BASE2_FILES, check-gdb.base%) (subdir_do, subdirs): Remove. (do-check-parallel, check/%): New targets. (clean): Remove outputs, temp, and cache directories. (saw_dash_j): New variable. (CHECK_TARGET): Use it. (check): Depend on all, site.exp. Rewrite. (check-single): Remove dependencies. (slow_tests, all_tests, reordered_tests): New variables.
2013-08-27 19:52:25 +02:00
# Note that we must resort to a recursive make invocation here,
# because GNU make 3.82 has a bug preventing MAKEFLAGS from being used
# in conditions.
check: all $(abs_builddir)/site.exp
$(MAKE) $(CHECK_TARGET)
check-read1:
$(MAKE) READ1="1" check
# All the hair to invoke dejagnu. A given invocation can just append
# $(RUNTESTFLAGS)
DO_RUNTEST = \
rootme=`pwd`; export rootme; \
srcdir=${srcdir} ; export srcdir ; \
EXPECT=${EXPECT} ; export EXPECT ; \
EXEEXT=${EXEEXT} ; export EXEEXT ; \
$(RPATH_ENVVAR)=$$rootme/../../expect:$$rootme/../../libstdc++:$$rootme/../../tk/unix:$$rootme/../../tcl/unix:$$rootme/../../bfd:$$rootme/../../opcodes:$$$(RPATH_ENVVAR); \
export $(RPATH_ENVVAR); \
if [ -f $${rootme}/../../expect/expect ] ; then \
TCL_LIBRARY=$${srcdir}/../../tcl/library ; \
export TCL_LIBRARY ; fi ; \
$(RUNTEST) --status
# TESTS exists for the user to pass on the command line to easily
# say "Only run these tests." With check-single it's not necessary, but
# with check-parallel there's no other way to (easily) specify a subset
# of tests. For consistency we support it for check-single as well.
# To specify all tests in a subdirectory, use TESTS=gdb.subdir/*.exp.
# E.g., make check TESTS="gdb.server/*.exp gdb.threads/*.exp".
Remove code that checks for GNU/non-GNU make Since GNU make is now required to build GDB, we can remove everything that checks whether the current make implemention is the GNU one or not. I simply removed the @GMAKE_TRUE@ prefixes and removed the whole lines that were prefixed with @GMAKE_FALSE@. I removed the code in the configure scripts that set those variables. I also removed the following bits from the configure scripts: AC_CHECK_PROGS(MAKE, make): GNU make already defines a MAKE variable internally to be used when invoking Makefiles recursively. I don't see this variable being used anywhere else (in scripts for example), so I think it's safe for removal. AC_PROG_MAKE_SET: This macro defines a SET_MAKE output variable, which is meant to be used in Makefiles to define the MAKE variable when using an implementation of make that doesn't already define it. Since we are now requiring GNU make, we don't need it anymore. Plus, I don't see SET_MAKE being used anywhere, so I don't think it was actually doing anything... gdb/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/gdbserver/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/testsuite/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate.
2016-11-17 18:00:10 +01:00
TESTS :=
Remove code that checks for GNU/non-GNU make Since GNU make is now required to build GDB, we can remove everything that checks whether the current make implemention is the GNU one or not. I simply removed the @GMAKE_TRUE@ prefixes and removed the whole lines that were prefixed with @GMAKE_FALSE@. I removed the code in the configure scripts that set those variables. I also removed the following bits from the configure scripts: AC_CHECK_PROGS(MAKE, make): GNU make already defines a MAKE variable internally to be used when invoking Makefiles recursively. I don't see this variable being used anywhere else (in scripts for example), so I think it's safe for removal. AC_PROG_MAKE_SET: This macro defines a SET_MAKE output variable, which is meant to be used in Makefiles to define the MAKE variable when using an implementation of make that doesn't already define it. Since we are now requiring GNU make, we don't need it anymore. Plus, I don't see SET_MAKE being used anywhere, so I don't think it was actually doing anything... gdb/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/gdbserver/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/testsuite/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate.
2016-11-17 18:00:10 +01:00
ifeq ($(strip $(TESTS)),)
expanded_tests_or_none :=
else
expanded_tests := $(patsubst $(srcdir)/%,%,$(wildcard $(addprefix $(srcdir)/,$(TESTS))))
expanded_tests_or_none := $(or $(expanded_tests),no-matching-tests-found)
endif
# Shorthand for running all the tests in a single directory.
Remove code that checks for GNU/non-GNU make Since GNU make is now required to build GDB, we can remove everything that checks whether the current make implemention is the GNU one or not. I simply removed the @GMAKE_TRUE@ prefixes and removed the whole lines that were prefixed with @GMAKE_FALSE@. I removed the code in the configure scripts that set those variables. I also removed the following bits from the configure scripts: AC_CHECK_PROGS(MAKE, make): GNU make already defines a MAKE variable internally to be used when invoking Makefiles recursively. I don't see this variable being used anywhere else (in scripts for example), so I think it's safe for removal. AC_PROG_MAKE_SET: This macro defines a SET_MAKE output variable, which is meant to be used in Makefiles to define the MAKE variable when using an implementation of make that doesn't already define it. Since we are now requiring GNU make, we don't need it anymore. Plus, I don't see SET_MAKE being used anywhere, so I don't think it was actually doing anything... gdb/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/gdbserver/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/testsuite/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate.
2016-11-17 18:00:10 +01:00
check-gdb.%:
$(MAKE) check TESTS="gdb.$*/*.exp"
switch to fully parallel mode This switches "make check" to fully parallel mode. One primary issue facing full parallelization is the overhead of "runtest". On my machine, if I "touch gdb.base/empty.exp", making a new file, and then "time runtest.exp", it takes 0.08 seconds. Multiply this by the 1008 (in my configuration) tests and you get ~80 seconds. This is the overhead that would theoretically be present if all tests were run in parallel. However, the problem isn't nearly as bad as this, for two reasons. First, you must divide by the number of jobs, assuming perfect parallelization -- reasonably true for small -j numbers, based on the results I see. Second, the current test suite parallelization approach bundles the tests, largely by directory, but also splitting up gdb.base into two halves. I was curious to see how the current bundling played out in practice, so I ran "make -j1 check RUNTEST='/bin/time runtest'". This invokes the parallel mode (thus the bundling) and then shows the time taken by each invocation of runtest. Then, I ran "/bin/time make -j3 check". (See below about -j2.) The time for the entire -j3 test run was the same as the time for "gdb.base1". What this means is that gdb.base1 is currently the time-limiting run, preventing further parallelization gains. So, I reason, whatever overhead we see from full parallelization will only be seen by "-j1" and "-j2". I then tried a -j2 test run. This does take longer than a -j3 build, meaning that the gdb.base1 job finishes and then proceeds to other runtest invocations. Finally I tried a -j2 test run with the appended patch. This was 9% slower than the -j2 run without the patch. I think that is a reasonable slowdown for what is probably a rare case. I believe this patch will yield faster test results for all -j values greater than 2. For -j3 on my machine, the test suite is a few seconds faster; I didn't try any larger -j values. For -j1, I went ahead and changed the Makefile so that, if no -j option is given, then the "check-single" mode is used. You can still use "make -j1 check" to get single-job parallel-mode, though of course there's no good reason to do so. This change is likely to speed up the plain "make check" scenario a little as we will now bypass dg-extract-results.sh. One drawback of this change is that "make -jN check" is now much more verbose. I generally only look at the .sum and .log files, but perhaps this will bother some. Another interesting question is scalability of the result. The slowest test, which limits the scalability, took 80.78 seconds. The mean of the remaining tests is 1.08 seconds. (Note that this is just a rough estimate, since there are still outliers.) This means we can run 80.78 / 1.08 =~ 74 tests in the time available. And, in this data set (slightly older than the above, but materially the same) there were 948 tests. So, I think the current test suite should scale ok up to about -j12. We could improve this number if need be by breaking up the biggest tests. 2013-11-04 Tom Tromey <tromey@redhat.com> * Makefile.in (TEST_DIRS): Remove. (TEST_TARGETS, check-parallel): Rewrite. (check-gdb.%, BASE1_FILES, BASE2_FILES, check-gdb.base%) (subdir_do, subdirs): Remove. (do-check-parallel, check/%): New targets. (clean): Remove outputs, temp, and cache directories. (saw_dash_j): New variable. (CHECK_TARGET): Use it. (check): Depend on all, site.exp. Rewrite. (check-single): Remove dependencies. (slow_tests, all_tests, reordered_tests): New variables.
2013-08-27 19:52:25 +02:00
check-single:
$(DO_RUNTEST) $(RUNTESTFLAGS) $(expanded_tests_or_none)
Improve analysis of racy testcases This is an initial attempt to introduce some mechanisms to identify racy testcases present in our testsuite. As can be seen in previous discussions, racy tests are really bothersome and cause our BuildBot to pollute the gdb-testers mailing list with hundreds of false-positives messages every month. Hopefully, identifying these racy tests in advance (and automatically) will contribute to the reduction of noise traffic to gdb-testers, maybe to the point where we will be able to send the failure messages directly to the authors of the commits. I spent some time trying to decide the best way to tackle this problem, and decided that there is no silver bullet. Racy tests are tricky and it is difficult to catch them, so the best solution I could find (for now?) is to run our testsuite a number of times in a row, and then compare the results (i.e., the gdb.sum files generated during each run). The more times you run the tests, the more racy tests you are likely to detect (at the expense of waiting longer and longer). You can also run the tests in parallel, which makes things faster (and contribute to catching more racy tests, because your machine will have less resources for each test and some of them are likely to fail when this happens). I did some tests in my machine (8-core i7, 16GB RAM), and running the whole GDB testsuite 5 times using -j6 took 23 minutes. Not bad. In order to run the racy test machinery, you need to specify the RACY_ITER environment variable. You will assign a number to this variable, which represents the number of times you want to run the tests. So, for example, if you want to run the whole testsuite 3 times in parallel (using 2 cores), you will do: make check RACY_ITER=3 -j2 It is also possible to use the TESTS variable and specify which tests you want to run: make check TEST='gdb.base/default.exp' RACY_ITER=3 -j2 And so on. The output files will be put at the directory gdb/testsuite/racy_outputs/. After make invokes the necessary rules to run the tests, it finally runs a Python script that will analyze the resulting gdb.sum files. This Python script will read each file, and construct a series of sets based on the results of the tests (one set for FAIL's, one for PASS'es, one for KFAIL's, etc.). It will then do some set operations and come up with a list of unique, sorted testcases that are racy. The algorithm behind this is: for state in PASS, FAIL, XFAIL, XPASS...; do if a test's state in every sumfile is $state; then it is not racy else it is racy (The algorithm is actually a bit more complex than that, because it takes into account other things in order to decide whether the test should be ignored or not). IOW, a test must have the same state in every sumfile. After processing everything, the script prints the racy tests it could identify on stdout. I am redirecting this to a file named racy.sum. Something else that I wasn't sure how to deal with was non-unique messages in our testsuite. I decided to do the same thing I do in our BuildBot: include a unique identifier in the end of message, like: gdb.base/xyz.exp: non-unique message gdb.base/xyz.exp: non-unique message <<2>> This means that you will have to be careful about them when you use the racy.sum file. I ran the script several times here, and it did a good job catching some well-known racy tests. Overall, I am satisfied with this approach and I think it will be helpful to have it upstream'ed. I also intend to extend our BuildBot and create new, specialized builders that will be responsible for detecting the racy tests every X number of days. 2016-03-05 Sergio Durigan Junior <sergiodj@redhat.com> * Makefile.in (DEFAULT_RACY_ITER): New variable. (CHECK_TARGET_TMP): Likewise. (check-single-racy): New rule. (check-parallel-racy): Likewise. (TEST_TARGETS): Adjust rule to account for RACY_ITER. (do-check-parallel-racy): New rule. (check-racy/%.exp): Likewise. * README (Racy testcases): New section. * analyze-racy-logs.py: New file.
2016-03-06 02:37:11 +01:00
check-single-racy:
-rm -rf cache racy_outputs temp
mkdir -p racy_outputs; \
racyiter="$(RACY_ITER)"; \
test "x$$racyiter" == "x" && \
racyiter=$(DEFAULT_RACY_ITER); \
if test $$racyiter -lt 2 ; then \
echo "RACY_ITER must be at least 2."; \
exit 1; \
fi; \
trap "exit" INT; \
for n in `seq $$racyiter` ; do \
mkdir -p racy_outputs/$$n; \
$(DO_RUNTEST) --outdir=racy_outputs/$$n $(RUNTESTFLAGS) \
$(expanded_tests_or_none); \
done; \
$(srcdir)/analyze-racy-logs.py \
`ls racy_outputs/*/gdb.sum` > racy.sum; \
sed -n '/=== gdb Summary ===/,$$ p' racy.sum
check-parallel:
-rm -rf cache outputs temp
switch to fully parallel mode This switches "make check" to fully parallel mode. One primary issue facing full parallelization is the overhead of "runtest". On my machine, if I "touch gdb.base/empty.exp", making a new file, and then "time runtest.exp", it takes 0.08 seconds. Multiply this by the 1008 (in my configuration) tests and you get ~80 seconds. This is the overhead that would theoretically be present if all tests were run in parallel. However, the problem isn't nearly as bad as this, for two reasons. First, you must divide by the number of jobs, assuming perfect parallelization -- reasonably true for small -j numbers, based on the results I see. Second, the current test suite parallelization approach bundles the tests, largely by directory, but also splitting up gdb.base into two halves. I was curious to see how the current bundling played out in practice, so I ran "make -j1 check RUNTEST='/bin/time runtest'". This invokes the parallel mode (thus the bundling) and then shows the time taken by each invocation of runtest. Then, I ran "/bin/time make -j3 check". (See below about -j2.) The time for the entire -j3 test run was the same as the time for "gdb.base1". What this means is that gdb.base1 is currently the time-limiting run, preventing further parallelization gains. So, I reason, whatever overhead we see from full parallelization will only be seen by "-j1" and "-j2". I then tried a -j2 test run. This does take longer than a -j3 build, meaning that the gdb.base1 job finishes and then proceeds to other runtest invocations. Finally I tried a -j2 test run with the appended patch. This was 9% slower than the -j2 run without the patch. I think that is a reasonable slowdown for what is probably a rare case. I believe this patch will yield faster test results for all -j values greater than 2. For -j3 on my machine, the test suite is a few seconds faster; I didn't try any larger -j values. For -j1, I went ahead and changed the Makefile so that, if no -j option is given, then the "check-single" mode is used. You can still use "make -j1 check" to get single-job parallel-mode, though of course there's no good reason to do so. This change is likely to speed up the plain "make check" scenario a little as we will now bypass dg-extract-results.sh. One drawback of this change is that "make -jN check" is now much more verbose. I generally only look at the .sum and .log files, but perhaps this will bother some. Another interesting question is scalability of the result. The slowest test, which limits the scalability, took 80.78 seconds. The mean of the remaining tests is 1.08 seconds. (Note that this is just a rough estimate, since there are still outliers.) This means we can run 80.78 / 1.08 =~ 74 tests in the time available. And, in this data set (slightly older than the above, but materially the same) there were 948 tests. So, I think the current test suite should scale ok up to about -j12. We could improve this number if need be by breaking up the biggest tests. 2013-11-04 Tom Tromey <tromey@redhat.com> * Makefile.in (TEST_DIRS): Remove. (TEST_TARGETS, check-parallel): Rewrite. (check-gdb.%, BASE1_FILES, BASE2_FILES, check-gdb.base%) (subdir_do, subdirs): Remove. (do-check-parallel, check/%): New targets. (clean): Remove outputs, temp, and cache directories. (saw_dash_j): New variable. (CHECK_TARGET): Use it. (check): Depend on all, site.exp. Rewrite. (check-single): Remove dependencies. (slow_tests, all_tests, reordered_tests): New variables.
2013-08-27 19:52:25 +02:00
$(MAKE) -k do-check-parallel; \
result=$$?; \
$(SHELL) $(srcdir)/dg-extract-results.sh \
switch to fully parallel mode This switches "make check" to fully parallel mode. One primary issue facing full parallelization is the overhead of "runtest". On my machine, if I "touch gdb.base/empty.exp", making a new file, and then "time runtest.exp", it takes 0.08 seconds. Multiply this by the 1008 (in my configuration) tests and you get ~80 seconds. This is the overhead that would theoretically be present if all tests were run in parallel. However, the problem isn't nearly as bad as this, for two reasons. First, you must divide by the number of jobs, assuming perfect parallelization -- reasonably true for small -j numbers, based on the results I see. Second, the current test suite parallelization approach bundles the tests, largely by directory, but also splitting up gdb.base into two halves. I was curious to see how the current bundling played out in practice, so I ran "make -j1 check RUNTEST='/bin/time runtest'". This invokes the parallel mode (thus the bundling) and then shows the time taken by each invocation of runtest. Then, I ran "/bin/time make -j3 check". (See below about -j2.) The time for the entire -j3 test run was the same as the time for "gdb.base1". What this means is that gdb.base1 is currently the time-limiting run, preventing further parallelization gains. So, I reason, whatever overhead we see from full parallelization will only be seen by "-j1" and "-j2". I then tried a -j2 test run. This does take longer than a -j3 build, meaning that the gdb.base1 job finishes and then proceeds to other runtest invocations. Finally I tried a -j2 test run with the appended patch. This was 9% slower than the -j2 run without the patch. I think that is a reasonable slowdown for what is probably a rare case. I believe this patch will yield faster test results for all -j values greater than 2. For -j3 on my machine, the test suite is a few seconds faster; I didn't try any larger -j values. For -j1, I went ahead and changed the Makefile so that, if no -j option is given, then the "check-single" mode is used. You can still use "make -j1 check" to get single-job parallel-mode, though of course there's no good reason to do so. This change is likely to speed up the plain "make check" scenario a little as we will now bypass dg-extract-results.sh. One drawback of this change is that "make -jN check" is now much more verbose. I generally only look at the .sum and .log files, but perhaps this will bother some. Another interesting question is scalability of the result. The slowest test, which limits the scalability, took 80.78 seconds. The mean of the remaining tests is 1.08 seconds. (Note that this is just a rough estimate, since there are still outliers.) This means we can run 80.78 / 1.08 =~ 74 tests in the time available. And, in this data set (slightly older than the above, but materially the same) there were 948 tests. So, I think the current test suite should scale ok up to about -j12. We could improve this number if need be by breaking up the biggest tests. 2013-11-04 Tom Tromey <tromey@redhat.com> * Makefile.in (TEST_DIRS): Remove. (TEST_TARGETS, check-parallel): Rewrite. (check-gdb.%, BASE1_FILES, BASE2_FILES, check-gdb.base%) (subdir_do, subdirs): Remove. (do-check-parallel, check/%): New targets. (clean): Remove outputs, temp, and cache directories. (saw_dash_j): New variable. (CHECK_TARGET): Use it. (check): Depend on all, site.exp. Rewrite. (check-single): Remove dependencies. (slow_tests, all_tests, reordered_tests): New variables.
2013-08-27 19:52:25 +02:00
`find outputs -name gdb.sum -print` > gdb.sum; \
$(SHELL) $(srcdir)/dg-extract-results.sh -L \
`find outputs -name gdb.log -print` > gdb.log; \
sed -n '/=== gdb Summary ===/,$$ p' gdb.sum; \
exit $$result
switch to fully parallel mode This switches "make check" to fully parallel mode. One primary issue facing full parallelization is the overhead of "runtest". On my machine, if I "touch gdb.base/empty.exp", making a new file, and then "time runtest.exp", it takes 0.08 seconds. Multiply this by the 1008 (in my configuration) tests and you get ~80 seconds. This is the overhead that would theoretically be present if all tests were run in parallel. However, the problem isn't nearly as bad as this, for two reasons. First, you must divide by the number of jobs, assuming perfect parallelization -- reasonably true for small -j numbers, based on the results I see. Second, the current test suite parallelization approach bundles the tests, largely by directory, but also splitting up gdb.base into two halves. I was curious to see how the current bundling played out in practice, so I ran "make -j1 check RUNTEST='/bin/time runtest'". This invokes the parallel mode (thus the bundling) and then shows the time taken by each invocation of runtest. Then, I ran "/bin/time make -j3 check". (See below about -j2.) The time for the entire -j3 test run was the same as the time for "gdb.base1". What this means is that gdb.base1 is currently the time-limiting run, preventing further parallelization gains. So, I reason, whatever overhead we see from full parallelization will only be seen by "-j1" and "-j2". I then tried a -j2 test run. This does take longer than a -j3 build, meaning that the gdb.base1 job finishes and then proceeds to other runtest invocations. Finally I tried a -j2 test run with the appended patch. This was 9% slower than the -j2 run without the patch. I think that is a reasonable slowdown for what is probably a rare case. I believe this patch will yield faster test results for all -j values greater than 2. For -j3 on my machine, the test suite is a few seconds faster; I didn't try any larger -j values. For -j1, I went ahead and changed the Makefile so that, if no -j option is given, then the "check-single" mode is used. You can still use "make -j1 check" to get single-job parallel-mode, though of course there's no good reason to do so. This change is likely to speed up the plain "make check" scenario a little as we will now bypass dg-extract-results.sh. One drawback of this change is that "make -jN check" is now much more verbose. I generally only look at the .sum and .log files, but perhaps this will bother some. Another interesting question is scalability of the result. The slowest test, which limits the scalability, took 80.78 seconds. The mean of the remaining tests is 1.08 seconds. (Note that this is just a rough estimate, since there are still outliers.) This means we can run 80.78 / 1.08 =~ 74 tests in the time available. And, in this data set (slightly older than the above, but materially the same) there were 948 tests. So, I think the current test suite should scale ok up to about -j12. We could improve this number if need be by breaking up the biggest tests. 2013-11-04 Tom Tromey <tromey@redhat.com> * Makefile.in (TEST_DIRS): Remove. (TEST_TARGETS, check-parallel): Rewrite. (check-gdb.%, BASE1_FILES, BASE2_FILES, check-gdb.base%) (subdir_do, subdirs): Remove. (do-check-parallel, check/%): New targets. (clean): Remove outputs, temp, and cache directories. (saw_dash_j): New variable. (CHECK_TARGET): Use it. (check): Depend on all, site.exp. Rewrite. (check-single): Remove dependencies. (slow_tests, all_tests, reordered_tests): New variables.
2013-08-27 19:52:25 +02:00
Improve analysis of racy testcases This is an initial attempt to introduce some mechanisms to identify racy testcases present in our testsuite. As can be seen in previous discussions, racy tests are really bothersome and cause our BuildBot to pollute the gdb-testers mailing list with hundreds of false-positives messages every month. Hopefully, identifying these racy tests in advance (and automatically) will contribute to the reduction of noise traffic to gdb-testers, maybe to the point where we will be able to send the failure messages directly to the authors of the commits. I spent some time trying to decide the best way to tackle this problem, and decided that there is no silver bullet. Racy tests are tricky and it is difficult to catch them, so the best solution I could find (for now?) is to run our testsuite a number of times in a row, and then compare the results (i.e., the gdb.sum files generated during each run). The more times you run the tests, the more racy tests you are likely to detect (at the expense of waiting longer and longer). You can also run the tests in parallel, which makes things faster (and contribute to catching more racy tests, because your machine will have less resources for each test and some of them are likely to fail when this happens). I did some tests in my machine (8-core i7, 16GB RAM), and running the whole GDB testsuite 5 times using -j6 took 23 minutes. Not bad. In order to run the racy test machinery, you need to specify the RACY_ITER environment variable. You will assign a number to this variable, which represents the number of times you want to run the tests. So, for example, if you want to run the whole testsuite 3 times in parallel (using 2 cores), you will do: make check RACY_ITER=3 -j2 It is also possible to use the TESTS variable and specify which tests you want to run: make check TEST='gdb.base/default.exp' RACY_ITER=3 -j2 And so on. The output files will be put at the directory gdb/testsuite/racy_outputs/. After make invokes the necessary rules to run the tests, it finally runs a Python script that will analyze the resulting gdb.sum files. This Python script will read each file, and construct a series of sets based on the results of the tests (one set for FAIL's, one for PASS'es, one for KFAIL's, etc.). It will then do some set operations and come up with a list of unique, sorted testcases that are racy. The algorithm behind this is: for state in PASS, FAIL, XFAIL, XPASS...; do if a test's state in every sumfile is $state; then it is not racy else it is racy (The algorithm is actually a bit more complex than that, because it takes into account other things in order to decide whether the test should be ignored or not). IOW, a test must have the same state in every sumfile. After processing everything, the script prints the racy tests it could identify on stdout. I am redirecting this to a file named racy.sum. Something else that I wasn't sure how to deal with was non-unique messages in our testsuite. I decided to do the same thing I do in our BuildBot: include a unique identifier in the end of message, like: gdb.base/xyz.exp: non-unique message gdb.base/xyz.exp: non-unique message <<2>> This means that you will have to be careful about them when you use the racy.sum file. I ran the script several times here, and it did a good job catching some well-known racy tests. Overall, I am satisfied with this approach and I think it will be helpful to have it upstream'ed. I also intend to extend our BuildBot and create new, specialized builders that will be responsible for detecting the racy tests every X number of days. 2016-03-05 Sergio Durigan Junior <sergiodj@redhat.com> * Makefile.in (DEFAULT_RACY_ITER): New variable. (CHECK_TARGET_TMP): Likewise. (check-single-racy): New rule. (check-parallel-racy): Likewise. (TEST_TARGETS): Adjust rule to account for RACY_ITER. (do-check-parallel-racy): New rule. (check-racy/%.exp): Likewise. * README (Racy testcases): New section. * analyze-racy-logs.py: New file.
2016-03-06 02:37:11 +01:00
check-parallel-racy:
-rm -rf cache racy_outputs temp
racyiter="$(RACY_ITER)"; \
test "x$$racyiter" == "x" && \
racyiter=$(DEFAULT_RACY_ITER); \
if test $$racyiter -lt 2 ; then \
echo "RACY_ITER must be at least 2."; \
exit 1; \
fi; \
trap "exit" INT; \
for n in `seq $$racyiter` ; do \
$(MAKE) -k do-check-parallel-racy \
RACY_OUTPUT_N=$$n; \
$(SHELL) $(srcdir)/dg-extract-results.sh \
`find racy_outputs/$$n -name gdb.sum -print` > \
racy_outputs/$$n/gdb.sum; \
$(SHELL) $(srcdir)/dg-extract-results.sh -L \
`find racy_outputs/$$n -name gdb.log -print` > \
racy_outputs/$$n/gdb.log; \
sed -n '/=== gdb Summary ===/,$$ p' racy_outputs/$$n/gdb.sum; \
done; \
$(srcdir)/analyze-racy-logs.py \
`ls racy_outputs/*/gdb.sum` > racy.sum; \
sed -n '/=== gdb Summary ===/,$$ p' racy.sum
switch to fully parallel mode This switches "make check" to fully parallel mode. One primary issue facing full parallelization is the overhead of "runtest". On my machine, if I "touch gdb.base/empty.exp", making a new file, and then "time runtest.exp", it takes 0.08 seconds. Multiply this by the 1008 (in my configuration) tests and you get ~80 seconds. This is the overhead that would theoretically be present if all tests were run in parallel. However, the problem isn't nearly as bad as this, for two reasons. First, you must divide by the number of jobs, assuming perfect parallelization -- reasonably true for small -j numbers, based on the results I see. Second, the current test suite parallelization approach bundles the tests, largely by directory, but also splitting up gdb.base into two halves. I was curious to see how the current bundling played out in practice, so I ran "make -j1 check RUNTEST='/bin/time runtest'". This invokes the parallel mode (thus the bundling) and then shows the time taken by each invocation of runtest. Then, I ran "/bin/time make -j3 check". (See below about -j2.) The time for the entire -j3 test run was the same as the time for "gdb.base1". What this means is that gdb.base1 is currently the time-limiting run, preventing further parallelization gains. So, I reason, whatever overhead we see from full parallelization will only be seen by "-j1" and "-j2". I then tried a -j2 test run. This does take longer than a -j3 build, meaning that the gdb.base1 job finishes and then proceeds to other runtest invocations. Finally I tried a -j2 test run with the appended patch. This was 9% slower than the -j2 run without the patch. I think that is a reasonable slowdown for what is probably a rare case. I believe this patch will yield faster test results for all -j values greater than 2. For -j3 on my machine, the test suite is a few seconds faster; I didn't try any larger -j values. For -j1, I went ahead and changed the Makefile so that, if no -j option is given, then the "check-single" mode is used. You can still use "make -j1 check" to get single-job parallel-mode, though of course there's no good reason to do so. This change is likely to speed up the plain "make check" scenario a little as we will now bypass dg-extract-results.sh. One drawback of this change is that "make -jN check" is now much more verbose. I generally only look at the .sum and .log files, but perhaps this will bother some. Another interesting question is scalability of the result. The slowest test, which limits the scalability, took 80.78 seconds. The mean of the remaining tests is 1.08 seconds. (Note that this is just a rough estimate, since there are still outliers.) This means we can run 80.78 / 1.08 =~ 74 tests in the time available. And, in this data set (slightly older than the above, but materially the same) there were 948 tests. So, I think the current test suite should scale ok up to about -j12. We could improve this number if need be by breaking up the biggest tests. 2013-11-04 Tom Tromey <tromey@redhat.com> * Makefile.in (TEST_DIRS): Remove. (TEST_TARGETS, check-parallel): Rewrite. (check-gdb.%, BASE1_FILES, BASE2_FILES, check-gdb.base%) (subdir_do, subdirs): Remove. (do-check-parallel, check/%): New targets. (clean): Remove outputs, temp, and cache directories. (saw_dash_j): New variable. (CHECK_TARGET): Use it. (check): Depend on all, site.exp. Rewrite. (check-single): Remove dependencies. (slow_tests, all_tests, reordered_tests): New variables.
2013-08-27 19:52:25 +02:00
# Turn a list of .exp files into "check/" targets. Only examine .exp
# files appearing in a gdb.* directory -- we don't want to pick up
# lib/ by mistake. For example, gdb.linespec/linespec.exp becomes
# check/gdb.linespec/linespec.exp. The list is generally sorted
# alphabetically, but we take a few tests known to be slow and push
# them to the front of the list to try to lessen the overall time
# taken by the test suite -- if one of these tests happens to be run
# late, it will cause the overall time to increase.
Remove code that checks for GNU/non-GNU make Since GNU make is now required to build GDB, we can remove everything that checks whether the current make implemention is the GNU one or not. I simply removed the @GMAKE_TRUE@ prefixes and removed the whole lines that were prefixed with @GMAKE_FALSE@. I removed the code in the configure scripts that set those variables. I also removed the following bits from the configure scripts: AC_CHECK_PROGS(MAKE, make): GNU make already defines a MAKE variable internally to be used when invoking Makefiles recursively. I don't see this variable being used anywhere else (in scripts for example), so I think it's safe for removal. AC_PROG_MAKE_SET: This macro defines a SET_MAKE output variable, which is meant to be used in Makefiles to define the MAKE variable when using an implementation of make that doesn't already define it. Since we are now requiring GNU make, we don't need it anymore. Plus, I don't see SET_MAKE being used anywhere, so I don't think it was actually doing anything... gdb/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/gdbserver/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/testsuite/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate.
2016-11-17 18:00:10 +01:00
ifeq ($(strip $(TESTS)),)
switch to fully parallel mode This switches "make check" to fully parallel mode. One primary issue facing full parallelization is the overhead of "runtest". On my machine, if I "touch gdb.base/empty.exp", making a new file, and then "time runtest.exp", it takes 0.08 seconds. Multiply this by the 1008 (in my configuration) tests and you get ~80 seconds. This is the overhead that would theoretically be present if all tests were run in parallel. However, the problem isn't nearly as bad as this, for two reasons. First, you must divide by the number of jobs, assuming perfect parallelization -- reasonably true for small -j numbers, based on the results I see. Second, the current test suite parallelization approach bundles the tests, largely by directory, but also splitting up gdb.base into two halves. I was curious to see how the current bundling played out in practice, so I ran "make -j1 check RUNTEST='/bin/time runtest'". This invokes the parallel mode (thus the bundling) and then shows the time taken by each invocation of runtest. Then, I ran "/bin/time make -j3 check". (See below about -j2.) The time for the entire -j3 test run was the same as the time for "gdb.base1". What this means is that gdb.base1 is currently the time-limiting run, preventing further parallelization gains. So, I reason, whatever overhead we see from full parallelization will only be seen by "-j1" and "-j2". I then tried a -j2 test run. This does take longer than a -j3 build, meaning that the gdb.base1 job finishes and then proceeds to other runtest invocations. Finally I tried a -j2 test run with the appended patch. This was 9% slower than the -j2 run without the patch. I think that is a reasonable slowdown for what is probably a rare case. I believe this patch will yield faster test results for all -j values greater than 2. For -j3 on my machine, the test suite is a few seconds faster; I didn't try any larger -j values. For -j1, I went ahead and changed the Makefile so that, if no -j option is given, then the "check-single" mode is used. You can still use "make -j1 check" to get single-job parallel-mode, though of course there's no good reason to do so. This change is likely to speed up the plain "make check" scenario a little as we will now bypass dg-extract-results.sh. One drawback of this change is that "make -jN check" is now much more verbose. I generally only look at the .sum and .log files, but perhaps this will bother some. Another interesting question is scalability of the result. The slowest test, which limits the scalability, took 80.78 seconds. The mean of the remaining tests is 1.08 seconds. (Note that this is just a rough estimate, since there are still outliers.) This means we can run 80.78 / 1.08 =~ 74 tests in the time available. And, in this data set (slightly older than the above, but materially the same) there were 948 tests. So, I think the current test suite should scale ok up to about -j12. We could improve this number if need be by breaking up the biggest tests. 2013-11-04 Tom Tromey <tromey@redhat.com> * Makefile.in (TEST_DIRS): Remove. (TEST_TARGETS, check-parallel): Rewrite. (check-gdb.%, BASE1_FILES, BASE2_FILES, check-gdb.base%) (subdir_do, subdirs): Remove. (do-check-parallel, check/%): New targets. (clean): Remove outputs, temp, and cache directories. (saw_dash_j): New variable. (CHECK_TARGET): Use it. (check): Depend on all, site.exp. Rewrite. (check-single): Remove dependencies. (slow_tests, all_tests, reordered_tests): New variables.
2013-08-27 19:52:25 +02:00
slow_tests = gdb.base/break-interp.exp gdb.base/interp.exp \
gdb.base/multi-forks.exp
Remove code that checks for GNU/non-GNU make Since GNU make is now required to build GDB, we can remove everything that checks whether the current make implemention is the GNU one or not. I simply removed the @GMAKE_TRUE@ prefixes and removed the whole lines that were prefixed with @GMAKE_FALSE@. I removed the code in the configure scripts that set those variables. I also removed the following bits from the configure scripts: AC_CHECK_PROGS(MAKE, make): GNU make already defines a MAKE variable internally to be used when invoking Makefiles recursively. I don't see this variable being used anywhere else (in scripts for example), so I think it's safe for removal. AC_PROG_MAKE_SET: This macro defines a SET_MAKE output variable, which is meant to be used in Makefiles to define the MAKE variable when using an implementation of make that doesn't already define it. Since we are now requiring GNU make, we don't need it anymore. Plus, I don't see SET_MAKE being used anywhere, so I don't think it was actually doing anything... gdb/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/gdbserver/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/testsuite/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate.
2016-11-17 18:00:10 +01:00
all_tests := $(shell cd $(srcdir) && find gdb.* -name '*.exp' -print)
reordered_tests := $(slow_tests) $(filter-out $(slow_tests),$(all_tests))
TEST_TARGETS := $(addprefix $(if $(RACY_ITER),check-racy,check)/,$(reordered_tests))
else
TEST_TARGETS := $(addprefix $(if $(RACY_ITER),check-racy,check)/,$(expanded_tests_or_none))
endif
switch to fully parallel mode This switches "make check" to fully parallel mode. One primary issue facing full parallelization is the overhead of "runtest". On my machine, if I "touch gdb.base/empty.exp", making a new file, and then "time runtest.exp", it takes 0.08 seconds. Multiply this by the 1008 (in my configuration) tests and you get ~80 seconds. This is the overhead that would theoretically be present if all tests were run in parallel. However, the problem isn't nearly as bad as this, for two reasons. First, you must divide by the number of jobs, assuming perfect parallelization -- reasonably true for small -j numbers, based on the results I see. Second, the current test suite parallelization approach bundles the tests, largely by directory, but also splitting up gdb.base into two halves. I was curious to see how the current bundling played out in practice, so I ran "make -j1 check RUNTEST='/bin/time runtest'". This invokes the parallel mode (thus the bundling) and then shows the time taken by each invocation of runtest. Then, I ran "/bin/time make -j3 check". (See below about -j2.) The time for the entire -j3 test run was the same as the time for "gdb.base1". What this means is that gdb.base1 is currently the time-limiting run, preventing further parallelization gains. So, I reason, whatever overhead we see from full parallelization will only be seen by "-j1" and "-j2". I then tried a -j2 test run. This does take longer than a -j3 build, meaning that the gdb.base1 job finishes and then proceeds to other runtest invocations. Finally I tried a -j2 test run with the appended patch. This was 9% slower than the -j2 run without the patch. I think that is a reasonable slowdown for what is probably a rare case. I believe this patch will yield faster test results for all -j values greater than 2. For -j3 on my machine, the test suite is a few seconds faster; I didn't try any larger -j values. For -j1, I went ahead and changed the Makefile so that, if no -j option is given, then the "check-single" mode is used. You can still use "make -j1 check" to get single-job parallel-mode, though of course there's no good reason to do so. This change is likely to speed up the plain "make check" scenario a little as we will now bypass dg-extract-results.sh. One drawback of this change is that "make -jN check" is now much more verbose. I generally only look at the .sum and .log files, but perhaps this will bother some. Another interesting question is scalability of the result. The slowest test, which limits the scalability, took 80.78 seconds. The mean of the remaining tests is 1.08 seconds. (Note that this is just a rough estimate, since there are still outliers.) This means we can run 80.78 / 1.08 =~ 74 tests in the time available. And, in this data set (slightly older than the above, but materially the same) there were 948 tests. So, I think the current test suite should scale ok up to about -j12. We could improve this number if need be by breaking up the biggest tests. 2013-11-04 Tom Tromey <tromey@redhat.com> * Makefile.in (TEST_DIRS): Remove. (TEST_TARGETS, check-parallel): Rewrite. (check-gdb.%, BASE1_FILES, BASE2_FILES, check-gdb.base%) (subdir_do, subdirs): Remove. (do-check-parallel, check/%): New targets. (clean): Remove outputs, temp, and cache directories. (saw_dash_j): New variable. (CHECK_TARGET): Use it. (check): Depend on all, site.exp. Rewrite. (check-single): Remove dependencies. (slow_tests, all_tests, reordered_tests): New variables.
2013-08-27 19:52:25 +02:00
do-check-parallel: $(TEST_TARGETS)
@:
Remove code that checks for GNU/non-GNU make Since GNU make is now required to build GDB, we can remove everything that checks whether the current make implemention is the GNU one or not. I simply removed the @GMAKE_TRUE@ prefixes and removed the whole lines that were prefixed with @GMAKE_FALSE@. I removed the code in the configure scripts that set those variables. I also removed the following bits from the configure scripts: AC_CHECK_PROGS(MAKE, make): GNU make already defines a MAKE variable internally to be used when invoking Makefiles recursively. I don't see this variable being used anywhere else (in scripts for example), so I think it's safe for removal. AC_PROG_MAKE_SET: This macro defines a SET_MAKE output variable, which is meant to be used in Makefiles to define the MAKE variable when using an implementation of make that doesn't already define it. Since we are now requiring GNU make, we don't need it anymore. Plus, I don't see SET_MAKE being used anywhere, so I don't think it was actually doing anything... gdb/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/gdbserver/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/testsuite/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate.
2016-11-17 18:00:10 +01:00
check/%.exp:
-mkdir -p outputs/$*
@$(DO_RUNTEST) GDB_PARALLEL=yes --outdir=outputs/$* $*.exp $(RUNTESTFLAGS)
Improve analysis of racy testcases This is an initial attempt to introduce some mechanisms to identify racy testcases present in our testsuite. As can be seen in previous discussions, racy tests are really bothersome and cause our BuildBot to pollute the gdb-testers mailing list with hundreds of false-positives messages every month. Hopefully, identifying these racy tests in advance (and automatically) will contribute to the reduction of noise traffic to gdb-testers, maybe to the point where we will be able to send the failure messages directly to the authors of the commits. I spent some time trying to decide the best way to tackle this problem, and decided that there is no silver bullet. Racy tests are tricky and it is difficult to catch them, so the best solution I could find (for now?) is to run our testsuite a number of times in a row, and then compare the results (i.e., the gdb.sum files generated during each run). The more times you run the tests, the more racy tests you are likely to detect (at the expense of waiting longer and longer). You can also run the tests in parallel, which makes things faster (and contribute to catching more racy tests, because your machine will have less resources for each test and some of them are likely to fail when this happens). I did some tests in my machine (8-core i7, 16GB RAM), and running the whole GDB testsuite 5 times using -j6 took 23 minutes. Not bad. In order to run the racy test machinery, you need to specify the RACY_ITER environment variable. You will assign a number to this variable, which represents the number of times you want to run the tests. So, for example, if you want to run the whole testsuite 3 times in parallel (using 2 cores), you will do: make check RACY_ITER=3 -j2 It is also possible to use the TESTS variable and specify which tests you want to run: make check TEST='gdb.base/default.exp' RACY_ITER=3 -j2 And so on. The output files will be put at the directory gdb/testsuite/racy_outputs/. After make invokes the necessary rules to run the tests, it finally runs a Python script that will analyze the resulting gdb.sum files. This Python script will read each file, and construct a series of sets based on the results of the tests (one set for FAIL's, one for PASS'es, one for KFAIL's, etc.). It will then do some set operations and come up with a list of unique, sorted testcases that are racy. The algorithm behind this is: for state in PASS, FAIL, XFAIL, XPASS...; do if a test's state in every sumfile is $state; then it is not racy else it is racy (The algorithm is actually a bit more complex than that, because it takes into account other things in order to decide whether the test should be ignored or not). IOW, a test must have the same state in every sumfile. After processing everything, the script prints the racy tests it could identify on stdout. I am redirecting this to a file named racy.sum. Something else that I wasn't sure how to deal with was non-unique messages in our testsuite. I decided to do the same thing I do in our BuildBot: include a unique identifier in the end of message, like: gdb.base/xyz.exp: non-unique message gdb.base/xyz.exp: non-unique message <<2>> This means that you will have to be careful about them when you use the racy.sum file. I ran the script several times here, and it did a good job catching some well-known racy tests. Overall, I am satisfied with this approach and I think it will be helpful to have it upstream'ed. I also intend to extend our BuildBot and create new, specialized builders that will be responsible for detecting the racy tests every X number of days. 2016-03-05 Sergio Durigan Junior <sergiodj@redhat.com> * Makefile.in (DEFAULT_RACY_ITER): New variable. (CHECK_TARGET_TMP): Likewise. (check-single-racy): New rule. (check-parallel-racy): Likewise. (TEST_TARGETS): Adjust rule to account for RACY_ITER. (do-check-parallel-racy): New rule. (check-racy/%.exp): Likewise. * README (Racy testcases): New section. * analyze-racy-logs.py: New file.
2016-03-06 02:37:11 +01:00
do-check-parallel-racy: $(TEST_TARGETS)
@:
Remove code that checks for GNU/non-GNU make Since GNU make is now required to build GDB, we can remove everything that checks whether the current make implemention is the GNU one or not. I simply removed the @GMAKE_TRUE@ prefixes and removed the whole lines that were prefixed with @GMAKE_FALSE@. I removed the code in the configure scripts that set those variables. I also removed the following bits from the configure scripts: AC_CHECK_PROGS(MAKE, make): GNU make already defines a MAKE variable internally to be used when invoking Makefiles recursively. I don't see this variable being used anywhere else (in scripts for example), so I think it's safe for removal. AC_PROG_MAKE_SET: This macro defines a SET_MAKE output variable, which is meant to be used in Makefiles to define the MAKE variable when using an implementation of make that doesn't already define it. Since we are now requiring GNU make, we don't need it anymore. Plus, I don't see SET_MAKE being used anywhere, so I don't think it was actually doing anything... gdb/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/gdbserver/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/testsuite/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate.
2016-11-17 18:00:10 +01:00
check-racy/%.exp:
-mkdir -p racy_outputs/$(RACY_OUTPUT_N)/$*
$(DO_RUNTEST) GDB_PARALLEL=yes \
--outdir=racy_outputs/$(RACY_OUTPUT_N)/$* $*.exp \
$(RUNTESTFLAGS)
Improve analysis of racy testcases This is an initial attempt to introduce some mechanisms to identify racy testcases present in our testsuite. As can be seen in previous discussions, racy tests are really bothersome and cause our BuildBot to pollute the gdb-testers mailing list with hundreds of false-positives messages every month. Hopefully, identifying these racy tests in advance (and automatically) will contribute to the reduction of noise traffic to gdb-testers, maybe to the point where we will be able to send the failure messages directly to the authors of the commits. I spent some time trying to decide the best way to tackle this problem, and decided that there is no silver bullet. Racy tests are tricky and it is difficult to catch them, so the best solution I could find (for now?) is to run our testsuite a number of times in a row, and then compare the results (i.e., the gdb.sum files generated during each run). The more times you run the tests, the more racy tests you are likely to detect (at the expense of waiting longer and longer). You can also run the tests in parallel, which makes things faster (and contribute to catching more racy tests, because your machine will have less resources for each test and some of them are likely to fail when this happens). I did some tests in my machine (8-core i7, 16GB RAM), and running the whole GDB testsuite 5 times using -j6 took 23 minutes. Not bad. In order to run the racy test machinery, you need to specify the RACY_ITER environment variable. You will assign a number to this variable, which represents the number of times you want to run the tests. So, for example, if you want to run the whole testsuite 3 times in parallel (using 2 cores), you will do: make check RACY_ITER=3 -j2 It is also possible to use the TESTS variable and specify which tests you want to run: make check TEST='gdb.base/default.exp' RACY_ITER=3 -j2 And so on. The output files will be put at the directory gdb/testsuite/racy_outputs/. After make invokes the necessary rules to run the tests, it finally runs a Python script that will analyze the resulting gdb.sum files. This Python script will read each file, and construct a series of sets based on the results of the tests (one set for FAIL's, one for PASS'es, one for KFAIL's, etc.). It will then do some set operations and come up with a list of unique, sorted testcases that are racy. The algorithm behind this is: for state in PASS, FAIL, XFAIL, XPASS...; do if a test's state in every sumfile is $state; then it is not racy else it is racy (The algorithm is actually a bit more complex than that, because it takes into account other things in order to decide whether the test should be ignored or not). IOW, a test must have the same state in every sumfile. After processing everything, the script prints the racy tests it could identify on stdout. I am redirecting this to a file named racy.sum. Something else that I wasn't sure how to deal with was non-unique messages in our testsuite. I decided to do the same thing I do in our BuildBot: include a unique identifier in the end of message, like: gdb.base/xyz.exp: non-unique message gdb.base/xyz.exp: non-unique message <<2>> This means that you will have to be careful about them when you use the racy.sum file. I ran the script several times here, and it did a good job catching some well-known racy tests. Overall, I am satisfied with this approach and I think it will be helpful to have it upstream'ed. I also intend to extend our BuildBot and create new, specialized builders that will be responsible for detecting the racy tests every X number of days. 2016-03-05 Sergio Durigan Junior <sergiodj@redhat.com> * Makefile.in (DEFAULT_RACY_ITER): New variable. (CHECK_TARGET_TMP): Likewise. (check-single-racy): New rule. (check-parallel-racy): Likewise. (TEST_TARGETS): Adjust rule to account for RACY_ITER. (do-check-parallel-racy): New rule. (check-racy/%.exp): Likewise. * README (Racy testcases): New section. * analyze-racy-logs.py: New file.
2016-03-06 02:37:11 +01:00
check/no-matching-tests-found:
@echo ""
@echo "No matching tests found."
@echo ""
# Utility rule invoked by step 2 of the build-perf rule.
Remove code that checks for GNU/non-GNU make Since GNU make is now required to build GDB, we can remove everything that checks whether the current make implemention is the GNU one or not. I simply removed the @GMAKE_TRUE@ prefixes and removed the whole lines that were prefixed with @GMAKE_FALSE@. I removed the code in the configure scripts that set those variables. I also removed the following bits from the configure scripts: AC_CHECK_PROGS(MAKE, make): GNU make already defines a MAKE variable internally to be used when invoking Makefiles recursively. I don't see this variable being used anywhere else (in scripts for example), so I think it's safe for removal. AC_PROG_MAKE_SET: This macro defines a SET_MAKE output variable, which is meant to be used in Makefiles to define the MAKE variable when using an implementation of make that doesn't already define it. Since we are now requiring GNU make, we don't need it anymore. Plus, I don't see SET_MAKE being used anywhere, so I don't think it was actually doing anything... gdb/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/gdbserver/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/testsuite/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate.
2016-11-17 18:00:10 +01:00
workers/%.worker:
mkdir -p gdb.perf/outputs/$*
$(DO_RUNTEST) --outdir=gdb.perf/outputs/$* lib/build-piece.exp WORKER=$* GDB_PARALLEL=gdb.perf $(RUNTESTFLAGS) GDB_PERFTEST_MODE=compile GDB_PERFTEST_SUBMODE=build-pieces
# Utility rule to build tests that support it in parallel.
# The build is broken into 3 steps distinguished by GDB_PERFTEST_SUBMODE:
# gen-workers, build-pieces, final.
#
# GDB_PERFTEST_MODE appears *after* RUNTESTFLAGS here because we don't want
# anything in RUNTESTFLAGS to override it.
#
# We don't delete the outputs directory here as these programs can take
# awhile to build, and perftest.exp has support for deciding whether to
# recompile them. If you want to remove these directories, make clean.
#
# The point of step 1 is to construct the set of worker tasks for step 2.
# All of the information needed by build-piece.exp is contained in the name
# of the generated .worker file.
Remove code that checks for GNU/non-GNU make Since GNU make is now required to build GDB, we can remove everything that checks whether the current make implemention is the GNU one or not. I simply removed the @GMAKE_TRUE@ prefixes and removed the whole lines that were prefixed with @GMAKE_FALSE@. I removed the code in the configure scripts that set those variables. I also removed the following bits from the configure scripts: AC_CHECK_PROGS(MAKE, make): GNU make already defines a MAKE variable internally to be used when invoking Makefiles recursively. I don't see this variable being used anywhere else (in scripts for example), so I think it's safe for removal. AC_PROG_MAKE_SET: This macro defines a SET_MAKE output variable, which is meant to be used in Makefiles to define the MAKE variable when using an implementation of make that doesn't already define it. Since we are now requiring GNU make, we don't need it anymore. Plus, I don't see SET_MAKE being used anywhere, so I don't think it was actually doing anything... gdb/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/gdbserver/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate. gdb/testsuite/ChangeLog: * Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines prefixed with @GMAKE_FALSE@. Update comment related to non-GNU make. * configure.ac: Remove checks for the make program. * configure: Re-generate.
2016-11-17 18:00:10 +01:00
build-perf: $(abs_builddir)/site.exp
rm -rf gdb.perf/workers
mkdir -p gdb.perf/workers
@: Step 1: Generate the build .worker files.
$(DO_RUNTEST) --directory=gdb.perf --outdir gdb.perf/workers GDB_PARALLEL=gdb.perf $(RUNTESTFLAGS) GDB_PERFTEST_MODE=compile GDB_PERFTEST_SUBMODE=gen-workers
@: Step 2: Compile the pieces. Here is the build parallelism.
$(MAKE) $$(cd gdb.perf && echo workers/*/*.worker)
@: Step 3: Do the final link.
$(DO_RUNTEST) --directory=gdb.perf --outdir gdb.perf GDB_PARALLEL=gdb.perf $(RUNTESTFLAGS) GDB_PERFTEST_MODE=compile GDB_PERFTEST_SUBMODE=final
# The default is to both compile and run the tests.
GDB_PERFTEST_MODE = both
check-perf: all $(abs_builddir)/site.exp
@if test ! -d gdb.perf; then mkdir gdb.perf; fi
$(DO_RUNTEST) --directory=gdb.perf --outdir gdb.perf GDB_PERFTEST_MODE=$(GDB_PERFTEST_MODE) $(RUNTESTFLAGS)
force:;
clean mostlyclean:
-rm -f *~ core *.o a.out xgdb *.x *.grt bigcore.corefile .gdb_history
-rm -f core.* *.tf *.cl tracecommandsscript copy1.txt zzz-gdbscript
-rm -f *.dwo *.dwp
switch to fully parallel mode This switches "make check" to fully parallel mode. One primary issue facing full parallelization is the overhead of "runtest". On my machine, if I "touch gdb.base/empty.exp", making a new file, and then "time runtest.exp", it takes 0.08 seconds. Multiply this by the 1008 (in my configuration) tests and you get ~80 seconds. This is the overhead that would theoretically be present if all tests were run in parallel. However, the problem isn't nearly as bad as this, for two reasons. First, you must divide by the number of jobs, assuming perfect parallelization -- reasonably true for small -j numbers, based on the results I see. Second, the current test suite parallelization approach bundles the tests, largely by directory, but also splitting up gdb.base into two halves. I was curious to see how the current bundling played out in practice, so I ran "make -j1 check RUNTEST='/bin/time runtest'". This invokes the parallel mode (thus the bundling) and then shows the time taken by each invocation of runtest. Then, I ran "/bin/time make -j3 check". (See below about -j2.) The time for the entire -j3 test run was the same as the time for "gdb.base1". What this means is that gdb.base1 is currently the time-limiting run, preventing further parallelization gains. So, I reason, whatever overhead we see from full parallelization will only be seen by "-j1" and "-j2". I then tried a -j2 test run. This does take longer than a -j3 build, meaning that the gdb.base1 job finishes and then proceeds to other runtest invocations. Finally I tried a -j2 test run with the appended patch. This was 9% slower than the -j2 run without the patch. I think that is a reasonable slowdown for what is probably a rare case. I believe this patch will yield faster test results for all -j values greater than 2. For -j3 on my machine, the test suite is a few seconds faster; I didn't try any larger -j values. For -j1, I went ahead and changed the Makefile so that, if no -j option is given, then the "check-single" mode is used. You can still use "make -j1 check" to get single-job parallel-mode, though of course there's no good reason to do so. This change is likely to speed up the plain "make check" scenario a little as we will now bypass dg-extract-results.sh. One drawback of this change is that "make -jN check" is now much more verbose. I generally only look at the .sum and .log files, but perhaps this will bother some. Another interesting question is scalability of the result. The slowest test, which limits the scalability, took 80.78 seconds. The mean of the remaining tests is 1.08 seconds. (Note that this is just a rough estimate, since there are still outliers.) This means we can run 80.78 / 1.08 =~ 74 tests in the time available. And, in this data set (slightly older than the above, but materially the same) there were 948 tests. So, I think the current test suite should scale ok up to about -j12. We could improve this number if need be by breaking up the biggest tests. 2013-11-04 Tom Tromey <tromey@redhat.com> * Makefile.in (TEST_DIRS): Remove. (TEST_TARGETS, check-parallel): Rewrite. (check-gdb.%, BASE1_FILES, BASE2_FILES, check-gdb.base%) (subdir_do, subdirs): Remove. (do-check-parallel, check/%): New targets. (clean): Remove outputs, temp, and cache directories. (saw_dash_j): New variable. (CHECK_TARGET): Use it. (check): Depend on all, site.exp. Rewrite. (check-single): Remove dependencies. (slow_tests, all_tests, reordered_tests): New variables.
2013-08-27 19:52:25 +02:00
-rm -rf outputs temp cache
-rm -rf gdb.perf/workers gdb.perf/outputs gdb.perf/temp gdb.perf/cache
-rm -f read1.so expect-read1
distclean maintainer-clean realclean: clean
-rm -f *~ core
-rm -f Makefile config.status *-init.exp
-rm -fr *.log summary detail *.plog *.sum *.psum site.*
* config/alpha/alpha-linux.mt: Remove file. * config/alpha/alpha.mt: Remove file. * config/alpha/alpha-osf1.mt: Remove file. * config/alpha/fbsd.mt: Remove file. * config/alpha/nbsd.mt: Remove file. * config/alpha/obsd.mt: Remove file. * config/arm/embed.mt: Remove file. * config/arm/linux.mt: Remove file. * config/arm/nbsd.mt: Remove file. * config/arm/obsd.mt: Remove file. * config/arm/wince.mt: Remove file. * config/avr/avr.mt: Remove file. * config/cris/cris.mt: Remove file. * config/frv/frv.mt: Remove file. * config/h8300/h8300.mt: Remove file. * config/i386/cygwin.mt: Remove file. * config/i386/fbsd64.mt: Remove file. * config/i386/fbsd.mt: Remove file. * config/i386/i386gnu.mt: Remove file. * config/i386/i386.mt: Remove file. * config/i386/i386sol2.mt: Remove file. * config/i386/linux64.mt: Remove file. * config/i386/linux.mt: Remove file. * config/i386/mingw.mt: Remove file. * config/i386/nbsd64.mt: Remove file. * config/i386/nbsd.mt: Remove file. * config/i386/nto.mt: Remove file. * config/i386/obsd64.mt: Remove file. * config/i386/obsd.mt: Remove file. * config/i386/sol2-64.mt: Remove file. * config/ia64/ia64.mt: Remove file. * config/ia64/linux.mt: Remove file. * config/iq2000/iq2000.mt: Remove file. * config/m32c/m32c.mt: Remove file. * config/m32r/linux.mt: Remove file. * config/m32r/m32r.mt: Remove file. * config/m68hc11/m68hc11.mt: Remove file. * config/m68k/linux.mt: Remove file. * config/m68k/monitor.mt: Remove file. * config/m68k/nbsd.mt: Remove file. * config/m68k/obsd.mt: Remove file. * config/m88k/obsd.mt: Remove file. * config/mep/mep.mt: Remove file. * config/mips/embed.mt: Remove file. * config/mips/irix5.mt: Remove file. * config/mips/irix6.mt: Remove file. * config/mips/linux.mt: Remove file. * config/mips/nbsd.mt: Remove file. * config/mips/obsd64.mt: Remove file. * config/mn10300/linux.mt: Remove file. * config/mn10300/mn10300.mt: Remove file. * config/mt/mt.mt: Remove file. * config/pa/hppahpux.mt: Remove file. * config/pa/hppa.mt: Remove file. * config/pa/linux.mt: Remove file. * config/pa/obsd.mt: Remove file. * config/powerpc/aix.mt: Remove file. * config/powerpc/linux.mt: Remove file. * config/powerpc/nbsd.mt: Remove file. * config/powerpc/obsd.mt: Remove file. * config/powerpc/ppc-eabi.mt: Remove file. * config/s390/s390.mt: Remove file. * config/score/embed.mt: Remove file. * config/sh/embed.mt: Remove file. * config/sh/linux.mt: Remove file. * config/sh/nbsd.mt: Remove file. * config/sh/obsd.mt: Remove file. * config/sh/sh64.mt: Remove file. * config/sparc/embed.mt: Remove file. * config/sparc/fbsd.mt: Remove file. * config/sparc/linux64.mt: Remove file. * config/sparc/linux.mt: Remove file. * config/sparc/nbsd64.mt: Remove file. * config/sparc/nbsd.mt: Remove file. * config/sparc/obsd64.mt: Remove file. * config/sparc/obsd.mt: Remove file. * config/sparc/sol2-64.mt: Remove file. * config/sparc/sol2.mt: Remove file. * config/sparc/sparc64.mt: Remove file. * config/sparc/sparc.mt: Remove file. * config/spu/spu.mt: Remove file. * config/v850/v850.mt: Remove file. * config/vax/nbsd.mt: Remove file. * config/vax/obsd.mt: Remove file. * config/vax/vax.mt: Remove file. * config/xstormy16/xstormy16.mt: Remove file. * config/xtensa/xtensa.mt: Remove file. * configure.tgt (gdb_target_cpu): Remove. Do not set anywhere. (gdb_target): Likewise. (gdb_target_obs): Document. Set for every target to contents of TDEPFILES in former .mt makefile fragment. * configure.ac (TARGET_OBS): Define. (target_makefile_frag, gdb_target_cpu): Do not define. * configure: Regenerate. * Makefile.in (MT_FLAGS): Remove. (GLOBAL_CFLAGS): Update. (TARGET_OBS): Substitute from configure. (DEPFILES): Remove TDEPFILES, add TARGET_OBS. (@target_makefile_frag@): Remove. doc/ChangeLog: * Makefile.in (Makefile): Do not depend on target_makefile_frag. testsuite/ChangeLog: * Makefile.in (Makefile): Do not depend on target_makefile_frag. (target_cpu): Remove.
2007-11-17 01:54:18 +01:00
Makefile : Makefile.in config.status $(host_makefile_frag)
$(SHELL) config.status
config.status: configure
$(SHELL) config.status --recheck
2011-03-07 18:03:51 +01:00
TAGS: force
2011-03-07 23:02:45 +01:00
find $(srcdir) -name '*.exp' -print | \
etags --regex='/proc[ \t]+\([^ \t]+\)/\1/' -
# Build the expect wrapper script that preloads the read1.so library.
expect-read1:
@echo Making expect-read1
@rm -f expect-read1-tmp
@touch expect-read1-tmp
@echo "# THIS FILE IS GENERATED -*- buffer-read-only: t -*- \n" >>expect-read1-tmp
@echo "# vi:set ro: */\n\n" >>expect-read1-tmp
@echo "# To regenerate this file, run:\n" >>expect-read1-tmp
@echo "# make clean; make/\n" >>expect-read1-tmp
@echo "export LD_PRELOAD=`pwd`/read1.so" >>expect-read1-tmp
@echo 'exec expect "$$@"' >>expect-read1-tmp
@chmod +x expect-read1-tmp
@mv expect-read1-tmp expect-read1
# Build the read1.so preload library. This overrides the `read'
# function, making it read one byte at a time. Running the testsuite
# with this catches racy tests.
read1.so: lib/read1.c
$(CC) -o $@ ${srcdir}/lib/read1.c -Wall -g -shared -fPIC $(CFLAGS)
# Build the read1 machinery.
.PHONY: read1
read1: read1.so expect-read1
Makefiles: Disable suffix rules and implicit rules Since we don't use suffix rules nor implicit rules in gdb, we can disable them. The advantage is a slightly faster make [1]. Here are some numbers about the speedup. I ran this on my trusty old Intel Q6600, so the time numbers are probably higher than what you'd get on any recent hardware. I ran "make" in the gdb/ directory of an already built repository (configured with --enable-targets=all). I recorded the time of execution (average of 5). I then ran "make -d" and recorded the number of printed lines, which gives a rough idea of the number of operations done. I compared the following configurations, to see the impact of both the empty .SUFFIXES target and the empty pattern rules, as well as running "make -r", which can be considered the "ideal" case. A - baseline B - baseline + .SUFFIXES C - baseline + pattern rules D - baseline + .SUFFIXES + pattern rules E - baseline + make -r config | time (s) | "make -d" ----------------------------- A | 5.74 | 2396643 B | 1.19 | 298469 C | 2.81 | 1266573 D | 1.13 | 245489 E | 1.01 | 163914 We can see that the empty .SUFFIXES target has a bigger impact than the empty pattern rules, but still it doesn't hurt to disable the implicit pattern rules as well. There are still some mentions of implicit rules I can't get rid of in the "make -d" output. For example, it's trying to build .c files from .w files: Looking for an implicit rule for '/home/simark/src/binutils-gdb/gdb/infrun.c'. Trying pattern rule with stem 'infrun'. Trying implicit prerequisite '/home/simark/src/binutils-gdb/gdb/infrun.w'. and trying to build Makefile.in from a bunch of extensions: Looking for an implicit rule for 'Makefile.in'. Trying pattern rule with stem 'Makefile.in'. Trying implicit prerequisite 'Makefile.in.o'. Trying pattern rule with stem 'Makefile.in'. Trying implicit prerequisite 'Makefile.in.c'. Trying pattern rule with stem 'Makefile.in'. Trying implicit prerequisite 'Makefile.in.cc'. ... many more ... If somebody knows how to disable them, we can do it, but at this point the returns are minimal, so it is not that important. I verified that both in-tree and out-of-tree builds work. [1] Switching from explicit rules to pattern rules for files in subdirectories actually made it slower, so this is kind of a way to redeem myself. But it the end it's faster than it was previously, so it was all worth it. :) gdb/ChangeLog: * disable-implicit-rules.mk: New file. * Makefile.in: Include disable-implicit-rules.mk. * data-directory/Makefile.in: Likewise. * gnulib/Makefile.in: Likewise. gdb/doc/ChangeLog: * Makefile.in: Likewise. gdb/gdbserver/ChangeLog: * Makefile.in: Include disable-implicit-rules.mk. gdb/testsuite/ChangeLog: * Makefile.in: Include disable-implicit-rules.mk.
2016-11-30 22:23:59 +01:00
# Disable implicit make rules.
include $(srcdir)/../disable-implicit-rules.mk