2013-09-13 00:51:16 +02:00
|
|
|
This is a collection of tests for GDB.
|
|
|
|
|
|
|
|
The file gdb/README contains basic instructions on how to run the
|
|
|
|
testsuite, while this file documents additional options and controls
|
|
|
|
that are available. The GDB wiki may also have some pages with ideas
|
|
|
|
and suggestions.
|
|
|
|
|
|
|
|
|
|
|
|
Running the Testsuite
|
|
|
|
*********************
|
|
|
|
|
|
|
|
There are two ways to run the testsuite and pass additional parameters
|
|
|
|
to DejaGnu. The first is to do `make check' in the main build
|
|
|
|
directory and specifying the makefile variable `RUNTESTFLAGS':
|
|
|
|
|
2019-05-17 17:48:36 +02:00
|
|
|
make check RUNTESTFLAGS='GDB=/usr/bin/gdb gdb.base/a2-run.exp'
|
2013-09-13 00:51:16 +02:00
|
|
|
|
|
|
|
The second is to cd to the testsuite directory and invoke the DejaGnu
|
|
|
|
`runtest' command directly.
|
|
|
|
|
|
|
|
cd testsuite
|
|
|
|
make site.exp
|
2019-05-17 17:48:36 +02:00
|
|
|
runtest GDB=/usr/bin/gdb
|
2013-09-13 00:51:16 +02:00
|
|
|
|
|
|
|
(The `site.exp' file contains a handful of useful variables like host
|
|
|
|
and target triplets, and pathnames.)
|
|
|
|
|
2016-02-11 20:36:39 +01:00
|
|
|
Parallel testing
|
|
|
|
****************
|
|
|
|
|
|
|
|
If not testing with a remote host (in DejaGnu's sense), you can run
|
|
|
|
the GDB test suite in a fully parallel mode. In this mode, each .exp
|
|
|
|
file runs separately and maybe simultaneously. The test suite ensures
|
|
|
|
that all the temporary files created by the test suite do not clash,
|
|
|
|
by putting them into separate directories. This mode is primarily
|
|
|
|
intended for use by the Makefile.
|
|
|
|
|
|
|
|
For GNU make, the Makefile tries to run the tests in parallel mode if
|
|
|
|
any -j option is given. For a non-GNU make, tests are not
|
|
|
|
parallelized.
|
|
|
|
|
|
|
|
If RUNTESTFLAGS is not empty, then by default the tests are
|
|
|
|
serialized. This can be overridden by either using the
|
|
|
|
`check-parallel' target in the Makefile, or by setting FORCE_PARALLEL
|
|
|
|
to any non-empty value:
|
|
|
|
|
2016-02-11 20:55:46 +01:00
|
|
|
make check-parallel RUNTESTFLAGS="--target_board=native-gdbserver"
|
|
|
|
make check RUNTESTFLAGS="--target_board=native-gdbserver" FORCE_PARALLEL=1
|
2016-02-11 20:36:39 +01:00
|
|
|
|
|
|
|
If you want to use runtest directly instead of using the Makefile, see
|
|
|
|
the description of GDB_PARALLEL below.
|
|
|
|
|
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
|
|
|
Racy testcases
|
|
|
|
**************
|
|
|
|
|
|
|
|
Sometimes, new testcases are added to the testsuite that are not
|
|
|
|
entirely deterministic, and can randomly pass or fail. We call them
|
|
|
|
"racy testcases", and they can be bothersome when one is comparing
|
|
|
|
different testsuite runs. In order to help identifying them, it is
|
|
|
|
possible to run the tests several times in a row and ask the testsuite
|
|
|
|
machinery to analyze the results. To do that, you need to specify the
|
|
|
|
RACY_ITER environment variable to make:
|
|
|
|
|
|
|
|
make check RACY_ITER=5 -j4
|
|
|
|
|
|
|
|
The value assigned to RACY_ITER represents the number of times you
|
|
|
|
wish to run the tests in sequence (in the example above, the entire
|
|
|
|
testsuite will be executed 5 times in a row, in parallel). It is also
|
|
|
|
possible to check just a specific test:
|
|
|
|
|
|
|
|
make check TESTS='gdb.base/default.exp' RACY_ITER=3
|
|
|
|
|
|
|
|
One can also decide to call the Makefile rules by hand inside the
|
|
|
|
gdb/testsuite directory, e.g.:
|
|
|
|
|
|
|
|
make check-paralell-racy -j4
|
|
|
|
|
|
|
|
In which case the value of the DEFAULT_RACY_ITER variable (inside
|
|
|
|
gdb/testsuite/Makefile.in) will be used to determine how many
|
|
|
|
iterations will be run.
|
|
|
|
|
|
|
|
After running the tests, you shall see a file name 'racy.sum' in the
|
|
|
|
gdb/testsuite directory. You can also inspect the generated *.log and
|
|
|
|
*.sum files by looking into the gdb/testsuite/racy_ouputs directory.
|
|
|
|
|
|
|
|
If you already have *.sum files generated from previous testsuite runs
|
|
|
|
and you would like to analyze them without having to run the testsuite
|
|
|
|
again, you can also use the 'analyze-racy-logs.py' script directly.
|
|
|
|
It is located in the gdb/testsuite/ directory, and it expects a list
|
|
|
|
of two or more *.sum files to be provided as its argument. For
|
|
|
|
example:
|
|
|
|
|
|
|
|
./gdb/testsuite/analyze-racy-logs.py testsuite-01/gdb.sum \
|
|
|
|
testsuite-02/gdb.sum testsuite-03/gdb.sum
|
|
|
|
|
|
|
|
The script will output its analysis report to the standard output.
|
|
|
|
|
2019-05-22 14:40:20 +02:00
|
|
|
Re-running Tests Outside The Testsuite
|
|
|
|
**************************************
|
|
|
|
|
|
|
|
When running a test, the arguments used to run GDB are saved to gdb.cmd and
|
|
|
|
all commands sent to GDB are saved to gdb.in. As well as being a reference
|
|
|
|
of the commands run, they can be used to manually re-run a test by using
|
|
|
|
the gdb.in file as a batch file to a GDB launched with the arguments in the
|
|
|
|
gdb.cmd file, for example:
|
|
|
|
$(cat outputs/gdb.base/store/gdb.cmd) -x outputs/gdb.base/store/gdb.in
|
|
|
|
|
|
|
|
Tests that run GDB multiple times will append .1, .2, .3 etc to the end
|
|
|
|
of each .cmd and .in file.
|
|
|
|
|
|
|
|
When gdbserver is launched as part of a test, a gdbserver.cmd will be created.
|
|
|
|
To re-run these tests, run the contents of gdbserver.cmd in a separate
|
|
|
|
terminal before running gdb, for example:
|
|
|
|
$(cat outputs/gdb.base/store/gdbserver.cmd)
|
|
|
|
Alternatively, if the test is run with GDBSERVER_DEBUG="replay", then this
|
|
|
|
will create a gdbserver.replay file which can be used with the gdbreplay tool,
|
|
|
|
instead of launching gdbserver.
|
|
|
|
|
2013-10-16 08:50:16 +02:00
|
|
|
Running the Performance Tests
|
|
|
|
*****************************
|
|
|
|
|
|
|
|
GDB Testsuite includes performance test cases, which are not run together
|
|
|
|
with other test cases, because performance test cases are slow and need
|
|
|
|
a quiet system. There are two ways to run the performance test cases.
|
|
|
|
The first is to do `make check-perf' in the main build directory:
|
|
|
|
|
|
|
|
make check-perf RUNTESTFLAGS="solib.exp SOLIB_COUNT=8"
|
|
|
|
|
|
|
|
The second is to cd to the testsuite directory and invoke the DejaGnu
|
|
|
|
`runtest' command directly.
|
|
|
|
|
|
|
|
cd testsuite
|
|
|
|
make site.exp
|
|
|
|
runtest GDB_PERFTEST_MODE=both GDB_PERFTEST_TIMEOUT=4000 --directory=gdb.perf solib.exp SOLIB_COUNT=8
|
|
|
|
|
|
|
|
Only "compile", "run" and "both" are valid to GDB_PERFTEST_MODE. They
|
|
|
|
stand for "compile tests only", "run tests only", and "compile and run
|
|
|
|
tests" respectively. "both" is the default. GDB_PERFTEST_TIMEOUT
|
|
|
|
specify the timeout, which is 3000 in default. The result of
|
|
|
|
performance test is appended in `testsuite/perftest.log'.
|
|
|
|
|
2013-09-13 00:51:16 +02:00
|
|
|
Testsuite Parameters
|
|
|
|
********************
|
|
|
|
|
|
|
|
The following parameters are DejaGNU variables that you can set to
|
|
|
|
affect the testsuite run globally.
|
|
|
|
|
|
|
|
GDB
|
|
|
|
|
|
|
|
By default, the testsuite exercises the GDB in the build directory,
|
|
|
|
but you can set GDB to be a pathname to a different version. For
|
|
|
|
instance,
|
|
|
|
|
|
|
|
make check RUNTESTFLAGS=GDB=/usr/bin/gdb
|
|
|
|
|
|
|
|
runs the testsuite on the GDB in /usr/bin.
|
|
|
|
|
|
|
|
GDBSERVER
|
|
|
|
|
|
|
|
You can set GDBSERVER to be a particular GDBserver of interest, so for
|
|
|
|
instance
|
|
|
|
|
|
|
|
make check RUNTESTFLAGS="GDB=/usr/bin/gdb GDBSERVER=/usr/bin/gdbserver"
|
|
|
|
|
|
|
|
checks both the installed GDB and GDBserver.
|
|
|
|
|
|
|
|
INTERNAL_GDBFLAGS
|
|
|
|
|
|
|
|
Command line options passed to all GDB invocations.
|
|
|
|
|
|
|
|
The default is "-nw -nx".
|
|
|
|
|
|
|
|
`-nw' disables any of the windowed interfaces.
|
|
|
|
`-nx' disables ~/.gdbinit, so that it doesn't interfere with
|
|
|
|
the tests.
|
|
|
|
|
|
|
|
This is actually considered an internal variable, and you
|
|
|
|
won't normally want to change it. However, in some situations,
|
|
|
|
this may be tweaked as a last resort if the testsuite doesn't
|
|
|
|
have direct support for the specifics of your environment.
|
|
|
|
The testsuite does not override a value provided by the user.
|
|
|
|
|
|
|
|
As an example, when testing an installed GDB that has been
|
|
|
|
configured with `--with-system-gdbinit', like by default,
|
|
|
|
you do not want ~/.gdbinit to interfere with tests, but, you
|
|
|
|
may want the system .gdbinit file loaded. As there's no way to
|
|
|
|
ask the testsuite, or GDB, to load the system gdbinit but
|
|
|
|
not ~/.gdbinit, a workaround is then to remove `-nx' from
|
|
|
|
INTERNAL_GDBFLAGS, and point $HOME at a directory without
|
|
|
|
a .gdbinit. For example:
|
|
|
|
|
|
|
|
cd testsuite
|
|
|
|
HOME=`pwd` runtest \
|
|
|
|
GDB=/usr/bin/gdb \
|
|
|
|
GDBSERVER=/usr/bin/gdbserver \
|
|
|
|
INTERNAL_GDBFLAGS=-nw
|
|
|
|
|
|
|
|
GDB_PARALLEL
|
|
|
|
|
2016-02-11 20:36:39 +01:00
|
|
|
To use parallel testing mode without using the the Makefile, set
|
|
|
|
GDB_PARALLEL on the runtest command line to "yes". Before starting
|
|
|
|
the tests, you must ensure that the directories cache, outputs, and
|
|
|
|
temp in the test suite build directory are either empty or have been
|
|
|
|
deleted. cache in particular is used to share data across invocations
|
|
|
|
of runtest, and files there may affect the test results. The Makefile
|
|
|
|
automatically does these deletions.
|
|
|
|
|
|
|
|
FORCE_PARALLEL
|
|
|
|
|
|
|
|
Setting FORCE_PARALLEL to any non-empty value forces parallel testing
|
|
|
|
mode even if RUNTESTFLAGS is not empty.
|
2013-09-13 00:51:16 +02:00
|
|
|
|
Add testing infrastruture bits for running with MI on a separate UI
With this, a specific test may can start GDB with MI on a separate UI
by using:
mi_gdb_start separate-mi-tty
In addition, it's also possible to run the whole testsuite with MI on
a separate tty, with:
make check RUNTESTFLAGS="FORCE_SEPARATE_MI_TTY=1"
gdb_main_spawn_id and mi_spawn_id are added so that tests may expect
output from either channel.
While at it, inferior_spawn_id was not being cleared when gdb exits,
unlike the other spawn ids, thus a test that starts gdb more than once
would end up using a stale spawn id.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* README (Testsuite Parameters): Document FORCE_SEPARATE_MI_TTY.
* lib/gdb.exp (default_gdb_exit): Clear inferior_spawn_id.
* lib/mi-support.exp (mi_uncatched_gdb_exit): Unset
gdb_main_spawn_id, mi_spawn_id, unset inferior_spawn_id.
(gdb_main_spawn_id, mi_spawn_id): Declare and
comment.
(mi_create_inferior_pty): New procedure,
factored out from default_mi_gdb_start.
(switch_gdb_spawn_id, mi_gdb_start_separate_mi_tty): New
procedures.
(default_mi_gdb_start): Call mi_gdb_start_separate_mi_tty if the
separate-mi-tty option is specified, or SEPARATE_MI_TTY is set.
Use mi_create_inferior_pty.
(mi_gdb_start): Use eval to pass down args list.
2016-06-21 02:11:55 +02:00
|
|
|
FORCE_SEPARATE_MI_TTY
|
|
|
|
|
|
|
|
Setting FORCE_MI_SEPARATE_UI to 1 forces all MI testing to start GDB
|
|
|
|
in console mode, with MI running on a separate TTY, on a secondary UI
|
|
|
|
started with "new-ui".
|
|
|
|
|
2013-09-13 00:51:16 +02:00
|
|
|
GDB_INOTIFY
|
|
|
|
|
|
|
|
For debugging parallel mode, it is handy to be able to see when a test
|
|
|
|
case writes to a file outside of its designated output directory.
|
|
|
|
|
|
|
|
If you have the inotify-tools package installed, you can set the
|
|
|
|
GDB_INOTIFY variable on the runtest command line. This will cause the
|
|
|
|
test suite to watch for parallel-unsafe file creations and report
|
|
|
|
them, both to stdout and in the test suite log file.
|
|
|
|
|
|
|
|
This setting is only meaningful in conjunction with GDB_PARALLEL.
|
|
|
|
|
2014-02-19 01:11:02 +01:00
|
|
|
TESTS
|
|
|
|
|
|
|
|
This variable is used to specify which set of tests to run.
|
|
|
|
It is passed to make (not runtest) and its contents are a space separated
|
|
|
|
list of tests to run.
|
|
|
|
|
|
|
|
If using GNU make then the contents are wildcard-expanded using
|
|
|
|
GNU make's $(wildcard) function. Test paths must be fully specified,
|
|
|
|
relative to the "testsuite" subdirectory. This allows one to run all
|
2014-12-09 21:50:03 +01:00
|
|
|
tests in a subdirectory by passing "gdb.subdir/*.exp", or more simply
|
|
|
|
by using the check-gdb.subdir target in the Makefile.
|
|
|
|
|
2014-02-19 01:11:02 +01:00
|
|
|
If for some strange reason one wanted to run all tests that begin with
|
|
|
|
the letter "d" that is also possible: TESTS="*/d*.exp".
|
|
|
|
|
|
|
|
Do not write */*.exp to specify all tests (assuming all tests are only
|
|
|
|
nested one level deep, which is not necessarily true). This will pick up
|
|
|
|
.exp files in ancillary directories like "lib" and "config".
|
|
|
|
Instead write gdb.*/*.exp.
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
make -j10 check TESTS="gdb.server/[s-w]*.exp */x*.exp"
|
|
|
|
|
|
|
|
If not using GNU make then the value is passed directly to runtest.
|
|
|
|
If not specified, all tests are run.
|
2013-09-13 00:51:16 +02:00
|
|
|
|
2014-08-20 19:55:54 +02:00
|
|
|
READ1
|
|
|
|
|
|
|
|
This make (not runtest) variable is used to specify whether the
|
|
|
|
testsuite preloads the read1.so library into expect. Any non-empty
|
|
|
|
value means true. See "Race detection" below.
|
|
|
|
|
Implement IPv6 support for GDB/gdbserver
This patch implements IPv6 support for both GDB and gdbserver. Based
on my research, it is the fourth attempt to do that since 2006. Since
I used ideas from all of the previous patches, I also added their
authors's names on the ChangeLogs as a way to recognize their
efforts. For reference sake, you can find the previous attempts at:
https://sourceware.org/ml/gdb-patches/2006-09/msg00192.html
https://sourceware.org/ml/gdb-patches/2014-02/msg00248.html
https://sourceware.org/ml/gdb-patches/2016-02/msg00226.html
The basic idea behind the patch is to start using the new
'getaddrinfo'/'getnameinfo' calls, which are responsible for
translating names and addresses in a protocol-independent way. This
means that if we ever have a new version of the IP protocol, we won't
need to change the code again (or, at least, won't have to change the
majority of the code).
The function 'getaddrinfo' returns a linked list of possible addresses
to connect to. Dealing with multiple addresses proved to be a hard
task with the current TCP auto-retry mechanism implemented on
ser-tcp:net_open. For example, when gdbserver listened only on an
IPv4 socket:
$ ./gdbserver --once 127.0.0.1:1234 ./a.out
and GDB was instructed to try to connect to both IPv6 and IPv4
sockets:
$ ./gdb -ex 'target extended-remote localhost:1234' ./a.out
the user would notice a somewhat big delay before GDB was able to
connect to the IPv4 socket. This happened because GDB was trying to
connect to the IPv6 socket first, and had to wait until the connection
timed out before it tried to connect to the IPv4 socket.
For that reason, I had to rewrite the main loop and implement a new
method for handling multiple connections. After some discussion,
Pedro and I agreed on the following algorithm:
1) For each entry returned by 'getaddrinfo', we try to open a socket
and connect to it.
2.a) If we have a successful 'connect', we just use that connection.
2.b) If we don't have a successfull 'connect', but if we've got a
ECONNREFUSED (meaning the the connection was refused), we keep track
of this fact by using a flag.
2.c) If we don't have a successfull 'connect', but if we've got a
EINPROGRESS (meaning that the connection is in progress), we perform
a 'select' call on the socket until we have a result (either a
successful connection, or an error on the socket).
3) If tcp_auto_retry is true, and we haven't gotten a successful
connection, and at least one of our attempts failed with
ECONNREFUSED, then we wait a little bit (i.e., call
'wait_for_connect'), check to see if there was a
timeout/interruption (in which case we bail out), and then go back
to (1).
After multiple tests, I was able to connect without delay on the
scenario described above, and was also able to connect in all other
types of scenarios.
I also implemented some hostname parsing functions (along with their
corresponding unit tests) which are used to help GDB and gdbserver to
parse hostname strings provided by the user. These new functions are
living inside common/netstuff.[ch]. I've had to do that since IPv6
introduces a new URL scheme, which defines that square brackets can be
used to enclose the host part and differentiate it from the
port (e.g., "[::1]:1234" means "host ::1, port 1234"). I spent some
time thinking about a reasonable way to interpret what the user wants,
and I came up with the following:
- If the user has provided a prefix that doesn't specify the protocol
version (i.e., "tcp:" or "udp:"), or if the user has not provided
any prefix, don't make any assumptions (i.e., assume AF_UNSPEC when
dealing with 'getaddrinfo') *unless* the host starts with "[" (in
which case, assume it's an IPv6 host).
- If the user has provided a prefix that does specify the protocol
version (i.e., "tcp4:", "tcp6:", "udp4:" or "udp6:"), then respect
that.
This method doesn't follow strictly what RFC 2732 proposes (that
literal IPv6 addresses should be provided enclosed in "[" and "]")
because IPv6 addresses still can be provided without square brackets
in our case, but since we have prefixes to specify protocol versions I
think this is not an issue.
Another thing worth mentioning is the new 'GDB_TEST_SOCKETHOST'
testcase parameter, which makes it possible to specify the
hostname (without the port) to be used when testing GDB and
gdbserver. For example, to run IPv6 tests:
$ make check-gdb RUNTESTFLAGS='GDB_TEST_SOCKETHOST=tcp6:[::1]'
Or, to run IPv4 tests:
$ make check-gdb RUNTESTFLAGS='GDB_TEST_SOCKETHOST=tcp4:127.0.0.1'
This required a few changes on the gdbserver-base.exp, and also a
minimal adjustment on gdb.server/run-without-local-binary.exp.
Finally, I've implemented a new testcase,
gdb.server/server-connect.exp, which is supposed to run on the native
host and perform various "smoke tests" using different connection
methods.
This patch has been regression-tested on BuildBot and locally, and
also built using a x86_64-w64-mingw32 GCC, and no problems were found.
gdb/ChangeLog:
2018-07-11 Sergio Durigan Junior <sergiodj@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Paul Fertser <fercerpav@gmail.com>
Tsutomu Seki <sekiriki@gmail.com>
Pedro Alves <palves@redhat.com>
* Makefile.in (SUBDIR_UNITTESTS_SRCS): Add
'unittests/parse-connection-spec-selftests.c'.
(COMMON_SFILES): Add 'common/netstuff.c'.
(HFILES_NO_SRCDIR): Add 'common/netstuff.h'.
* NEWS (Changes since GDB 8.2): Mention IPv6 support.
* common/netstuff.c: New file.
* common/netstuff.h: New file.
* ser-tcp.c: Include 'netstuff.h' and 'wspiapi.h'.
(wait_for_connect): Update comment. New parameter
'gdb::optional<int> sock' instead of 'struct serial *scb'.
Use 'sock' directly instead of 'scb->fd'.
(try_connect): New function, with code from 'net_open'.
(net_open): Rewrite main loop to deal with multiple
sockets/addresses. Handle IPv6-style hostnames; implement
support for IPv6 connections.
* unittests/parse-connection-spec-selftests.c: New file.
gdb/gdbserver/ChangeLog:
2018-07-11 Sergio Durigan Junior <sergiodj@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Paul Fertser <fercerpav@gmail.com>
Tsutomu Seki <sekiriki@gmail.com>
* Makefile.in (SFILES): Add '$(srcdir)/common/netstuff.c'.
(OBS): Add 'common/netstuff.o'.
(GDBREPLAY_OBS): Likewise.
* gdbreplay.c: Include 'wspiapi.h' and 'netstuff.h'.
(remote_open): Implement support for IPv6
connections.
* remote-utils.c: Include 'netstuff.h', 'filestuff.h'
and 'wspiapi.h'.
(handle_accept_event): Accept connections from IPv6 sources.
(remote_prepare): Handle IPv6-style hostnames; implement
support for IPv6 connections.
(remote_open): Implement support for printing connections from
IPv6 sources.
gdb/testsuite/ChangeLog:
2018-07-11 Sergio Durigan Junior <sergiodj@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Paul Fertser <fercerpav@gmail.com>
Tsutomu Seki <sekiriki@gmail.com>
* README (Testsuite Parameters): Mention new 'GDB_TEST_SOCKETHOST'
parameter.
* boards/native-extended-gdbserver.exp: Do not set 'sockethost'
by default.
* boards/native-gdbserver.exp: Likewise.
* gdb.server/run-without-local-binary.exp: Improve regexp used
for detecting when a remote debugging connection succeeds.
* gdb.server/server-connect.exp: New file.
* lib/gdbserver-support.exp (gdbserver_default_get_comm_port):
Do not prefix the port number with ":".
(gdbserver_start): New global GDB_TEST_SOCKETHOST. Implement
support for detecting and using it. Add '$debughost_gdbserver'
to the list of arguments used to start gdbserver. Handle case
when gdbserver cannot resolve a network name.
gdb/doc/ChangeLog:
2018-07-11 Sergio Durigan Junior <sergiodj@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Paul Fertser <fercerpav@gmail.com>
Tsutomu Seki <sekiriki@gmail.com>
* gdb.texinfo (Remote Connection Commands): Add explanation
about new IPv6 support. Add new connection prefixes.
2018-05-18 07:29:24 +02:00
|
|
|
GDB_TEST_SOCKETHOST
|
|
|
|
|
|
|
|
This variable can provide the hostname/address that should be used
|
|
|
|
when performing GDBserver-related tests. This is useful in some
|
|
|
|
situations, e.g., when you want to test the IPv6 connectivity of GDB
|
|
|
|
and GDBserver, or when using a different hostname/address is needed.
|
|
|
|
For example, to make GDB and GDBserver use IPv6-only connections, you
|
|
|
|
can do:
|
|
|
|
|
|
|
|
make check TESTS="gdb.server/*.exp" RUNTESTFLAGS='GDB_TEST_SOCKETHOST=tcp6:[::1]'
|
|
|
|
|
|
|
|
Note that only a hostname/address can be provided, without a port
|
|
|
|
number.
|
|
|
|
|
Implement timestamp'ed output on "make check"
It is unfortunately not uncommon to have tests hanging on some of the
BuildBot workers. For example, the ppc64be/ppc64le+gdbserver builders
are especially in a bad state when it comes to testing GDB/gdbserver,
and we can have builds that take an absurd amount of time to
finish (almost 1 week for one single build, for example).
It may be hard to diagnose these failures, because sometimes we don't
have access to the faulty systems, and other times we're just too busy
to wait and check which test is actually hanging. During one of our
conversations about the topic, someone proposed that it would be a
good idea to have a timestamp put together with stdout output, so that
we can come back later and examine which tests are taking too long to
complete.
Here's my proposal to do this. The very first thing I tried to do was
to use "ts(1)" to achieve this feature, and it obviously worked, but
the problem is that I'm afraid "ts(1)" may not be widely available on
every system we support. Therefore, I decided to implement a *very*
simple version of "ts(1)", in Python 3, which basically does the same
thing: iterate over the stdin lines, and prepend a timestamp onto
them.
As for testsuite/Makefile.in, the user can now specify two new
variables to enable timestamp'ed output: TS (which enables the
output), and TS_FORMAT (optional, used to specify another timestamp
format according to "strftime").
Here's an example of how the output looks like:
...
[Nov 22 17:07:19] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/call-strs.exp ...
[Nov 22 17:07:19] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/step-over-no-symbols.exp ...
[Nov 22 17:07:20] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/all-architectures-6.exp ...
[Nov 22 17:07:20] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/hashline3.exp ...
[Nov 22 17:07:20] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/max-value-size.exp ...
[Nov 22 17:07:20] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/quit-live.exp ...
[Nov 22 17:07:46] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/paginate-bg-execution.exp ...
[Nov 22 17:07:56] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/gcore-buffer-overflow.exp ...
[Nov 22 17:07:56] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/gcore-relro.exp ...
[Nov 22 17:07:56] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/watchpoint-delete.exp ...
[Nov 22 17:07:56] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/breakpoint-in-ro-region.exp ...
[Nov 22 17:07:56] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/vla-sideeffect.exp ...
[Nov 22 17:07:57] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/unload.exp ...
...
(What, gdb.base/quit-live.exp is taking 26 seconds to complete?!)
Output to stderr is not timestamp'ed, but I don't think that will be a
problem for us. If it is, we can revisit the solution and extend it.
gdb/testsuite/ChangeLog:
2018-11-25 Sergio Durigan Junior <sergiodj@redhat.com>
* Makefile.in (TIMESTAMP): New variable.
(check-single): Add $(TIMESTAMP) to the end of $(DO_RUNTEST)
command.
(check-single-racy): Likewise.
(check/%.exp): Likewise.
(check-racy/%.exp): Likewise.
(workers/%.worker): Likewise.
(build-perf): Likewise.
(check-perf): Likewise.
* README: Describe new "TS" and "TS_FORMAT" variables.
* print-ts.py: New file.
2018-11-22 22:45:33 +01:00
|
|
|
TS
|
|
|
|
|
|
|
|
This variable turns on the timestamp printing for each line of "make
|
|
|
|
check". Note that the timestamp will be printed on stdout output
|
|
|
|
only. In other words, there will be no timestamp output on either
|
|
|
|
gdb.sum and gdb.log files. If you would like to enable timestamp
|
|
|
|
printing, you can do:
|
|
|
|
|
|
|
|
make check TS=1
|
|
|
|
|
|
|
|
TS_FORMAT
|
|
|
|
|
|
|
|
You can provide a custom format for timestamp printing with this
|
|
|
|
variable. The format must be a string compatible with "strftime".
|
|
|
|
This variable is only useful when the TS variable is also provided.
|
|
|
|
If you would like to change the output format of the timestamp, you
|
|
|
|
can do:
|
|
|
|
|
|
|
|
make check TS=1 TS_FORMAT='[%b %H:%S]'
|
|
|
|
|
2019-05-17 15:35:23 +02:00
|
|
|
GDB_DEBUG
|
|
|
|
|
|
|
|
When set gdb debug is sent to the file gdb.debug in the test output
|
|
|
|
directory. It should be set to a comma separated list of gdb debug
|
|
|
|
components.
|
|
|
|
For example, to turn on debugging for infrun and target, you can do:
|
|
|
|
|
|
|
|
make check GDB_DEBUG="infrun,target"
|
|
|
|
|
2019-04-12 17:36:51 +02:00
|
|
|
GDBSERVER_DEBUG
|
|
|
|
|
2019-04-30 17:00:29 +02:00
|
|
|
When set gdbserver debug is sent to the a file in the test output directory.
|
|
|
|
It should be set to a comma separated list of the following options:
|
|
|
|
debug - write gdbserver debug to gdbserver.debug.
|
|
|
|
remote - write gdbserver remote debug to gdbserver.debug.
|
|
|
|
replay - write a replay log to the file gdbserver.replay for use
|
|
|
|
with gdbreplay.
|
|
|
|
Alternatively, it can be set to "all" to turn on all the above
|
|
|
|
For example, to turn on gdbserver debugging, you can do:
|
2019-04-12 17:36:51 +02:00
|
|
|
|
2019-04-30 17:00:29 +02:00
|
|
|
make check GDBSERVER_DEBUG="debug,replay"
|
2019-04-12 17:36:51 +02:00
|
|
|
|
2014-08-20 19:55:54 +02:00
|
|
|
Race detection
|
|
|
|
**************
|
|
|
|
|
|
|
|
The testsuite includes a mechanism that helps detect test races.
|
|
|
|
|
|
|
|
For example, say the program running under expect outputs "abcd", and
|
|
|
|
a test does something like this:
|
|
|
|
|
|
|
|
expect {
|
|
|
|
"a.*c" {
|
|
|
|
}
|
|
|
|
"b" {
|
|
|
|
}
|
|
|
|
"a" {
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Which case happens to match depends on what expect manages to read
|
|
|
|
into its internal buffer in one go. If it manages to read three bytes
|
|
|
|
or more, then the first case matches. If it manages to read two
|
|
|
|
bytes, then the second case matches. If it manages to read only one
|
|
|
|
byte, then the third case matches.
|
|
|
|
|
|
|
|
To help detect these cases, the race detection mechanism preloads a
|
|
|
|
library into expect that forces the `read' system call to always
|
|
|
|
return at most 1 byte.
|
|
|
|
|
|
|
|
To enable this, either pass a non-empty value in the READ1 make
|
|
|
|
variable, or use the check-read1 make target instead of check.
|
|
|
|
|
|
|
|
Examples:
|
|
|
|
|
|
|
|
make -j10 check-read1 TESTS="*/paginate-*.exp"
|
|
|
|
make -j10 check READ1="1"
|
|
|
|
|
2013-09-13 00:51:16 +02:00
|
|
|
Testsuite Configuration
|
|
|
|
***********************
|
|
|
|
|
|
|
|
It is possible to adjust the behavior of the testsuite by defining
|
|
|
|
the global variables listed below, either in a `site.exp' file,
|
|
|
|
or in a board file.
|
|
|
|
|
|
|
|
gdb_test_timeout
|
|
|
|
|
|
|
|
Defining this variable changes the default timeout duration used
|
|
|
|
during communication with GDB. More specifically, the global variable
|
|
|
|
used during testing is `timeout', but this variable gets reset to
|
|
|
|
`gdb_test_timeout' at the beginning of each testcase, which ensures
|
|
|
|
that any local change to `timeout' in a testcase does not affect
|
|
|
|
subsequent testcases.
|
|
|
|
|
|
|
|
This global variable comes in handy when the debugger is slower than
|
|
|
|
normal due to the testing environment, triggering unexpected `TIMEOUT'
|
|
|
|
test failures. Examples include when testing on a remote machine, or
|
|
|
|
against a system where communications are slow.
|
|
|
|
|
|
|
|
If not specifically defined, this variable gets automatically defined
|
|
|
|
to the same value as `timeout' during the testsuite initialization.
|
|
|
|
The default value of the timeout is defined in the file
|
|
|
|
`testsuite/config/unix.exp' (at least for Unix hosts; board files may
|
|
|
|
have their own values).
|
|
|
|
|
Set timeout for gdb.reverse/*.exp test cases
Hi,
This patch is to add a new board setting gdb_reverse_timeout, which is
used to set timeout for all gdb.reverse test cases, which are usually
very slow and cause some TIMEOUT failures, for example, on some arm
boards. We have some alternatives to this approach, but I am not
satisfied with them:
- Increase the timeout value. This is the global change, and it may
cause some delay where actual failures happen.
- Set timeout by gdb_reverse_timeout in every gdb.reverse/*.exp.
Then, we have to touch every file under gdb.reverse.
In this patch, we choose a central place to set timeout for all tests
in gdb.reverse, which is convenient.
gdb/testsuite:
2014-05-20 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (gdb_init): Set timeout if test file is under
gdb.reverse directory and gdb_reverse_timeout exists in board
setting.
* README: Document gdb_reverse_timeout.
2014-05-09 09:06:12 +02:00
|
|
|
gdb_reverse_timeout
|
|
|
|
|
|
|
|
Defining this variable changes the default timeout duration when tests
|
|
|
|
under gdb.reverse directory are running. Process record and reverse
|
|
|
|
debugging is so slow that its tests have unexpected `TIMEOUT' test
|
|
|
|
failures. This global variable is useful to bump up the value of
|
|
|
|
`timeout' for gdb.reverse tests and doesn't cause any delay where
|
|
|
|
actual failures happen in the rest of the testsuite.
|
|
|
|
|
2013-09-13 00:51:16 +02:00
|
|
|
|
|
|
|
Board Settings
|
|
|
|
**************
|
|
|
|
|
|
|
|
DejaGNU includes the concept of a "board file", which specifies
|
|
|
|
testing details for a particular target (which are often bare circuit
|
|
|
|
boards, thus the name).
|
|
|
|
|
|
|
|
In the GDB testsuite specifically, the board file may include a
|
|
|
|
number of "board settings" that test cases may check before deciding
|
|
|
|
whether to exercise a particular feature. For instance, a board
|
|
|
|
lacking any I/O devices, or perhaps simply having its I/O devices
|
|
|
|
not wired up, should set `noinferiorio'.
|
|
|
|
|
|
|
|
Here are the supported board settings:
|
|
|
|
|
|
|
|
gdb,cannot_call_functions
|
|
|
|
|
|
|
|
The board does not support inferior call, that is, invoking inferior
|
|
|
|
functions in GDB.
|
|
|
|
|
|
|
|
gdb,can_reverse
|
|
|
|
|
|
|
|
The board supports reverse execution.
|
|
|
|
|
|
|
|
gdb,no_hardware_watchpoints
|
|
|
|
|
|
|
|
The board does not support hardware watchpoints.
|
|
|
|
|
|
|
|
gdb,nofileio
|
|
|
|
|
|
|
|
GDB is unable to intercept target file operations in remote and
|
|
|
|
perform them on the host.
|
|
|
|
|
|
|
|
gdb,noinferiorio
|
|
|
|
|
|
|
|
The board is unable to provide I/O capability to the inferior.
|
|
|
|
|
|
|
|
gdb,noresults
|
|
|
|
|
|
|
|
A program will not return an exit code or result code (or the value
|
|
|
|
of the result is undefined, and should not be looked at).
|
|
|
|
|
|
|
|
gdb,nosignals
|
|
|
|
|
|
|
|
The board does not support signals.
|
|
|
|
|
|
|
|
gdb,skip_huge_test
|
|
|
|
|
|
|
|
Skip time-consuming tests on the board with slow connection.
|
|
|
|
|
|
|
|
gdb,skip_float_tests
|
|
|
|
|
|
|
|
Skip tests related to floating point.
|
|
|
|
|
|
|
|
gdb,use_precord
|
|
|
|
|
|
|
|
The board supports process record.
|
|
|
|
|
2014-07-12 02:22:25 +02:00
|
|
|
gdb_init_command
|
|
|
|
gdb_init_commands
|
|
|
|
|
|
|
|
Commands to send to GDB every time a program is about to be run. The
|
|
|
|
first of these settings defines a single command as a string. The
|
|
|
|
second defines a TCL list of commands being a string each. The commands
|
|
|
|
are sent one by one in a sequence, first from `gdb_init_command', if any,
|
|
|
|
followed by individual commands from `gdb_init_command', if any, in this
|
|
|
|
list's order.
|
|
|
|
|
2013-09-13 00:51:16 +02:00
|
|
|
gdb_server_prog
|
|
|
|
|
|
|
|
The location of GDBserver. If GDBserver somewhere other than its
|
|
|
|
default location is used in test, specify the location of GDBserver in
|
|
|
|
this variable. The location is a file name for GDBserver, and may be
|
|
|
|
either absolute or relative to the testsuite subdirectory of the build
|
|
|
|
directory.
|
|
|
|
|
|
|
|
in_proc_agent
|
|
|
|
|
|
|
|
The location of the in-process agent (used for fast tracepoints and
|
|
|
|
other special tests). If the in-process agent of interest is anywhere
|
|
|
|
other than its default location, set this variable. The location is a
|
|
|
|
filename, and may be either absolute or relative to the testsuite
|
|
|
|
subdirectory of the build directory.
|
|
|
|
|
|
|
|
noargs
|
|
|
|
|
|
|
|
GDB does not support argument passing for inferior.
|
|
|
|
|
|
|
|
no_long_long
|
|
|
|
|
|
|
|
The board does not support type long long.
|
|
|
|
|
|
|
|
use_cygmon
|
|
|
|
|
|
|
|
The board is running the monitor Cygmon.
|
|
|
|
|
|
|
|
use_gdb_stub
|
|
|
|
|
|
|
|
The tests are running with a GDB stub.
|
|
|
|
|
Teach the testsuite that GDBserver reliably reports program exits.
Running catch-syscall.exp against a gdbserver that actually supports
it, we get:
FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
FAIL: gdb.base/catch-syscall.exp: continue until exit at catch syscall with unused syscall (mlock) (the program exited)
FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
The fail pattern is:
Catchpoint 2 (call to syscall exit_group), 0x000000323d4baa29 in _exit () from /lib64/libc.so.6
(gdb) PASS: gdb.base/catch-syscall.exp: program has called exit_group
delete breakpoints
Delete all breakpoints? (y or n) y
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break exit
Breakpoint 3 at 0x323d438bf0
(gdb) continue
Continuing.
[Inferior 1 (process 21081) exited normally]
That "break exit" + "continue" comes from:
> # gdb_continue_to_end:
> # The case where the target uses stubs has to be handled specially. If a
> # stub is used, we set a breakpoint at exit because we cannot rely on
> # exit() behavior of a remote target.
> #
The native-gdbserver.exp board, used to test against gdbserver in
"target remote" mode, triggers that case ($use_gdb_stub is true). So
gdb_continue_to_end doesn't work for catch-syscall.exp as here we
catch the exit_group and continue from that, expecting to see a real
program exit. I was about to post a patch that changes
catch-syscall.exp to call a new function that just always does what
gdb_continue_to_end does in the !$use_gdb_stub case. But, since
GDBserver doesn't really need this, in the end I thought it better to
teach the testsuite that there are stubs that know how to report
program exits, by adding a new "exit_is_reliable" board variable that
then gdb_continue_to_end checks.
Tested on x86_64 Fedora 17, native and gdbserver.
gdb/testsuite/
2013-10-02 Pedro Alves <palves@redhat.com>
* README (Board Settings): Document "exit_is_reliable".
* lib/gdb.exp (gdb_continue_to_end): Check whether the board says
running to exit reliably reports program exits.
* boards/native-gdbserver.exp: Set exit_is_reliable in the board
info.
* boards/native-stdio-gdbserver.exp: Likewise.
2013-10-02 13:44:20 +02:00
|
|
|
exit_is_reliable
|
|
|
|
|
|
|
|
Set to true if GDB can assume that letting the program run to end
|
|
|
|
reliably results in program exits being reported as such, as opposed
|
|
|
|
to, e.g., the program ending in an infinite loop or the board
|
|
|
|
crashing/resetting. If not set, this defaults to $use_gdb_stub. In
|
|
|
|
other words, native targets are assumed reliable by default, and
|
|
|
|
remote stubs assumed unreliable.
|
|
|
|
|
2013-09-13 00:51:16 +02:00
|
|
|
gdb,predefined_tsv
|
|
|
|
|
|
|
|
The predefined trace state variables the board has.
|
|
|
|
|
2015-11-26 15:49:04 +01:00
|
|
|
gdb,no_thread_names
|
|
|
|
|
|
|
|
The target doesn't support thread names.
|
2013-09-13 00:51:16 +02:00
|
|
|
|
2019-02-13 13:28:38 +01:00
|
|
|
gdb,pie_flag
|
|
|
|
|
|
|
|
The flag required to force the compiler to produce position-independent
|
|
|
|
executables.
|
|
|
|
|
|
|
|
gdb,pie_ldflag
|
|
|
|
|
|
|
|
The flag required to force the linker to produce position-independent
|
|
|
|
executables.
|
|
|
|
|
2018-12-13 16:20:49 +01:00
|
|
|
gdb,nopie_flag
|
|
|
|
|
|
|
|
The flag required to force the compiler to produce non-position-independent
|
|
|
|
executables.
|
|
|
|
|
2019-05-17 15:35:23 +02:00
|
|
|
gdb,debug
|
|
|
|
|
|
|
|
When set gdb debug is sent to the file gdb.debug in the test output
|
|
|
|
directory. It should be set to a comma separated list of gdb debug
|
|
|
|
components. For example, to turn on debugging for infrun and target, set to
|
|
|
|
"infrun,target".
|
|
|
|
|
2019-04-12 17:36:51 +02:00
|
|
|
gdbserver,debug
|
|
|
|
|
|
|
|
When set gdbserver debug is sent to the file gdbserver.debug in the test
|
2019-04-30 17:00:29 +02:00
|
|
|
output directory. For valid values see the entry for GDBSERVER_DEBUG.
|
2019-04-12 17:36:51 +02:00
|
|
|
|
2013-09-13 00:51:16 +02:00
|
|
|
Testsuite Organization
|
|
|
|
**********************
|
|
|
|
|
|
|
|
The testsuite is entirely contained in `gdb/testsuite'. The main
|
|
|
|
directory of the testsuite includes some makefiles and configury, but
|
|
|
|
these are minimal, and used for little besides cleaning up, since the
|
|
|
|
tests themselves handle the compilation of the programs that GDB will
|
|
|
|
run.
|
|
|
|
|
|
|
|
The file `testsuite/lib/gdb.exp' contains common utility procs useful
|
|
|
|
for all GDB tests, while the directory testsuite/config contains
|
|
|
|
configuration-specific files, typically used for special-purpose
|
|
|
|
definitions of procs like `gdb_load' and `gdb_start'.
|
|
|
|
|
|
|
|
The tests themselves are to be found in directories named
|
|
|
|
'testsuite/gdb.* and subdirectories of those. The names of the test
|
|
|
|
files must always end with ".exp". DejaGNU collects the test files by
|
|
|
|
wildcarding in the test directories, so both subdirectories and
|
|
|
|
individual files typically get chosen and run in alphabetical order.
|
|
|
|
|
|
|
|
The following lists some notable types of subdirectories and what they
|
|
|
|
are for. Since DejaGNU finds test files no matter where they are
|
|
|
|
located, and since each test file sets up its own compilation and
|
|
|
|
execution environment, this organization is simply for convenience and
|
|
|
|
intelligibility.
|
|
|
|
|
|
|
|
gdb.base
|
|
|
|
|
|
|
|
This is the base testsuite. The tests in it should apply to all
|
|
|
|
configurations of GDB (but generic native-only tests may live here).
|
|
|
|
The test programs should be in the subset of C that is both valid
|
|
|
|
ANSI/ISO C, and C++.
|
|
|
|
|
|
|
|
gdb.<lang>
|
|
|
|
|
|
|
|
Language-specific tests for any language besides C. Examples are
|
Remove Java support
This patch removes the Java support from gdb. gcj has not seen much
development or use for years now, and was recently removed from GCC.
This patch changes gdb to follow; in the unlikely event that there are
still users using gcj, they can continue to use an older gdb to debug.
Or, they can debug in C++ mode.
Built and regtested on x86-64 Fedora 24.
2016-10-06 Tom Tromey <tom@tromey.com>
* MAINTAINERS: Remove Java test maintainer.
* varobj.h (java_varobj_ops): Don't declare.
* valprint.h (struct value_print_options)
<pascal_static_field_print>: Update comment.
* utils.c (producer_is_gcc): Remove java reference.
* symtab.h (struct general_symbol_info): Remove java references.
(SYMBOL_SEARCH_NAME): Likewise.
* objfiles.c (allocate_objfile): Update comment.
* linespec.c (find_linespec_symbols): Remove java references.
* gnu-v3-abi.c (gnuv3_rtti_type, gnuv3_baseclass_offset): Remove
java references.
* gdbtypes.h (struct cplus_struct_type) <is_java>: Remove.
(TYPE_CPLUS_REALLY_JAVA): Remove.
* c-varobj.c (enum vsections): Update comment.
* symtab.c (symbol_set_language, symbol_set_names)
(symbol_natural_name, symbol_demangled_name)
(demangle_for_lookup, symbol_matches_domain)
(default_make_symbol_completion_list_break_on_1): Remove java
references.
(JAVA_PREFIX, JAVA_PREFIX_LEN): Remove.
* psymtab.c (match_partial_symbol, psymtab_search_name)
(lookup_partial_symbol): Remove java references.
* dwarf2read.c (find_slot_in_mapped_hash): Remove java references.
(add_partial_symbol, dwarf2_compute_name, dwarf2_physname)
(dwarf2_add_member_fn, is_vtable_name, read_structure_type)
(process_structure_scope, read_subroutine_type)
(read_subrange_type, load_partial_dies)
(new_symbol_full, determine_prefix, typename_concat)
(dwarf2_name): Remove java references.
(set_cu_language): Treat Java as C++.
* c-typeprint.c (c_type_print_args): Remove java reference.
* defs.h (enum language) <language_java>: Remove.
* Makefile.in (SFILES, HFILES_NO_SRCDIR, COMMON_OBS, YYFILES)
(YYOBJ, local-maintainer-clean): Don't mention java files.
* jv-exp.y, jv-lang.c, jv-lang.h, jv-typeprint.c, jv-valprint.c,
jv-varobj.c: Remove.
2016-10-06 Tom Tromey <tom@tromey.com>
* guile.texi (Types In Guile): Remove Java mentions.
* python.texi (Types In Python): Remove Java mentions.
* gdb.texinfo (Address Locations, Supported Languages)
(Index Section Format): Remove Java mentions.
2016-10-06 Tom Tromey <tom@tromey.com>
* gdb.compile/compile.exp: Change java tests to rust.
* gdb.base/setshow.exp: Change java tests to rust.
* gdb.base/default.exp: Remove java from language list.
* README (Examples): Update language example.
* gdb.python/py-lookup-type.exp (test_lookup_type): Remove java
test.
* lib/gdb.exp (skip_java_tests): Remove.
* lib/java.exp: Remove.
* gdb.java: Remove.
2016-10-05 16:44:34 +02:00
|
|
|
gdb.cp for C++ and gdb.rust for Rust.
|
2013-09-13 00:51:16 +02:00
|
|
|
|
|
|
|
gdb.<platform>
|
|
|
|
|
|
|
|
Non-portable tests. The tests are specific to a specific
|
2015-03-20 17:15:15 +01:00
|
|
|
configuration (host or target), such as eCos.
|
2013-09-13 00:51:16 +02:00
|
|
|
|
|
|
|
gdb.arch
|
|
|
|
|
|
|
|
Architecture-specific tests that are (usually) cross-platform.
|
|
|
|
|
|
|
|
gdb.<subsystem>
|
|
|
|
|
|
|
|
Tests that exercise a specific GDB subsystem in more depth. For
|
|
|
|
instance, gdb.disasm exercises various disassemblers, while
|
|
|
|
gdb.stabs tests pathways through the stabs symbol reader.
|
|
|
|
|
2013-10-16 08:50:16 +02:00
|
|
|
gdb.perf
|
|
|
|
|
|
|
|
GDB performance tests.
|
|
|
|
|
2013-09-13 00:51:16 +02:00
|
|
|
Writing Tests
|
|
|
|
*************
|
|
|
|
|
|
|
|
In many areas, the GDB tests are already quite comprehensive; you
|
|
|
|
should be able to copy existing tests to handle new cases. Be aware
|
|
|
|
that older tests may use obsolete practices but have not yet been
|
|
|
|
updated.
|
|
|
|
|
|
|
|
You should try to use `gdb_test' whenever possible, since it includes
|
|
|
|
cases to handle all the unexpected errors that might happen. However,
|
|
|
|
it doesn't cost anything to add new test procedures; for instance,
|
|
|
|
gdb.base/exprs.exp defines a `test_expr' that calls `gdb_test'
|
|
|
|
multiple times.
|
|
|
|
|
|
|
|
Only use `send_gdb' and `gdb_expect' when absolutely necessary. Even
|
|
|
|
if GDB has several valid responses to a command, you can use
|
|
|
|
`gdb_test_multiple'. Like `gdb_test', `gdb_test_multiple' recognizes
|
|
|
|
internal errors and unexpected prompts.
|
|
|
|
|
|
|
|
Do not write tests which expect a literal tab character from GDB. On
|
|
|
|
some operating systems (e.g. OpenBSD) the TTY layer expands tabs to
|
|
|
|
spaces, so by the time GDB's output reaches `expect' the tab is gone.
|
|
|
|
|
|
|
|
The source language programs do *not* need to be in a consistent
|
|
|
|
style. Since GDB is used to debug programs written in many different
|
|
|
|
styles, it's worth having a mix of styles in the testsuite; for
|
|
|
|
instance, some GDB bugs involving the display of source lines might
|
|
|
|
never manifest themselves if the test programs used GNU coding style
|
|
|
|
uniformly.
|
|
|
|
|
|
|
|
Some testcase results need more detailed explanation:
|
|
|
|
|
|
|
|
KFAIL
|
|
|
|
|
|
|
|
Use KFAIL for known problem of GDB itself. You must specify the GDB
|
|
|
|
bug report number, as in these sample tests:
|
|
|
|
|
|
|
|
kfail "gdb/13392" "continue to marker 2"
|
|
|
|
|
|
|
|
or
|
|
|
|
|
|
|
|
setup_kfail gdb/13392 "*-*-*"
|
|
|
|
kfail "continue to marker 2"
|
|
|
|
|
|
|
|
|
|
|
|
XFAIL
|
|
|
|
|
|
|
|
Short for "expected failure", this indicates a known problem with the
|
|
|
|
environment. This could include limitations of the operating system,
|
|
|
|
compiler version, and other components.
|
|
|
|
|
|
|
|
This example from gdb.base/attach-pie-misread.exp is a sanity check
|
|
|
|
for the target environment:
|
|
|
|
|
|
|
|
# On x86_64 it is commonly about 4MB.
|
|
|
|
if {$stub_size > 25000000} {
|
|
|
|
xfail "stub size $stub_size is too large"
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
You should provide bug report number for the failing component of the
|
|
|
|
environment, if such bug report is available, as with this example
|
|
|
|
referring to a GCC problem:
|
|
|
|
|
|
|
|
if {[test_compiler_info {gcc-[0-3]-*}]
|
|
|
|
|| [test_compiler_info {gcc-4-[0-5]-*}]} {
|
|
|
|
setup_xfail "gcc/46955" *-*-*
|
|
|
|
}
|
|
|
|
gdb_test "python print ttype.template_argument(2)" "&C::c"
|
|
|
|
|
|
|
|
Note that it is also acceptable, and often preferable, to avoid
|
|
|
|
running the test at all. This is the better option if the limitation
|
|
|
|
is intrinsic to the environment, rather than a bug expected to be
|
|
|
|
fixed in the near future.
|
Make native gdbserver boards no longer be "remote" (in DejaGnu terms)
This commit finally clears the "isremote" flag in the native-gdbserver
and native-stdio-gdbserver boards. The goal is to make all "native"
boards be considered not remote in DejaGnu terms, like the
native-extended-gdbserver board is too.
DejaGnu automatically considers boards remote if their names don't
match the local hostname. That means that native-gdbserver and
native-extended-gdbserver are considered remote by default by DejaGnu,
even though they run locally. native-extended-gdbserver, however,
overrides its isremote flag to force it to be not remote. So we are
in that weird state where native-gdbserver is considered remote, and
native-extended-gdbserver is considered not remote.
A recent set of commits fixed all the problems (and some more) exposed
by testing with --target_board=native-gdbserver and
--target_board=native-stdio-gdbserver with isremote forced off on
x86-64 GNU/Linux. I believe we're good to go now.
The native-stdio-gdbserver.exp/remote-stdio-gdbserver.exp boards
required deep non-obvious modifications unfortunately... The problem
is that if a board is not remote, then DejaGnu doesn't call
${board}_spawn / ${board}_exec at all, and the
native-stdio-gdbserver.exp board relies on those procedures being
called. To fix that, this commit redesigns how the stdio boards hook
into the testing framework to spawn gdbserver. IMO, this is a good
change anyway, because the way its done currently is a bit of a hack,
and the result turns out to be simpler, even. With this commit, they
now no longer load the "gdbserver" generic config, and hook at the
mi_gdb_target_load/gdb_reload level instead, making them more like
traditional board files.
To share code between native-stdio-gdbserver.exp and
remote-stdio-gdbserver.exp, a new shared stdio-gdbserver-base.exp file
is created.
Instead of having each native board clear isremote manually, boards
source the new "local-board.exp" file.
This also adds a new section to testsuite/README file discussing
local/remote/native, so that we can easily refer to it.
gdb/testsuite/ChangeLog:
2017-10-16 Pedro Alves <palves@redhat.com>
Simon Marchi <simon.marchi@polymtl.ca>
* README (Local vs Remote vs Native): New section.
* boards/local-board.exp: New file, with bits factored out from
...
* boards/native-extended-gdbserver.exp: ... here. Load
"local-board".
* boards/native-gdbserver.exp: Load "local-board".
(${board}_spawn, ${board}_exec): Delete.
* boards/native-stdio-gdbserver.exp: Most contents factored out to
...
* boards/stdio-gdbserver-base.exp: ... this new file.
* boards/native-stdio-gdbserver.exp: Reimplement, by loading
"stdio-gdbserver-base" and defining a get_target_remote_pipe_cmd
procedure.
* boards/remote-stdio-gdbserver.exp: Load stdio-gdbserver-base
instead of native-stdio-gdbserver. Don't set gdb_server_prog nor
stdio_gdbserver_command.
(${board}_get_remote_address, ${board}_get_comm_port)
(${board}_download, ${board}_upload): Delete.
(get_target_remote_pipe_cmd): New.
2017-10-16 21:24:21 +02:00
|
|
|
|
|
|
|
Local vs Remote vs Native
|
|
|
|
*************************
|
|
|
|
|
|
|
|
It's unfortunately easy to get confused in the testsuite about what's
|
|
|
|
native and what's not, what's remote and what's not. The confusion is
|
|
|
|
caused by the overlap in vocabulary between DejaGnu and GDB.
|
|
|
|
|
|
|
|
From a DejaGnu point of view:
|
|
|
|
|
|
|
|
- native: the host or target board is considered native if the its
|
|
|
|
triplet is the same as the build system's triplet,
|
|
|
|
|
|
|
|
- remote: the host or target board is considered remote if it's
|
|
|
|
running on a different machine, and thus require ssh, for example,
|
|
|
|
to run commands, versus simply running commands directly.
|
|
|
|
|
|
|
|
Note that they are not mutually exclusive, as you can have a remote
|
|
|
|
machine that has the same triplet as the build machine.
|
|
|
|
|
|
|
|
From a GDB point of view:
|
|
|
|
|
|
|
|
- native: when GDB uses system calls such as ptrace to interact
|
|
|
|
directly with processes on the same system its running on,
|
|
|
|
|
|
|
|
- remote: when GDB speaks the RSP (Remote Serial Protocol) with
|
|
|
|
another program doing the ptrace stuff.
|
|
|
|
|
|
|
|
Note that they are mutually exclusive. An inferior can only be either
|
|
|
|
debugged with the native target, or with the remote target a specific
|
|
|
|
time.
|
|
|
|
|
|
|
|
That means that there are cases where the target is not remote for
|
|
|
|
DejaGnu, but is remote for GDB (e.g. running GDBserver on the same
|
|
|
|
machine).
|
|
|
|
|
|
|
|
You can also have a remote target for DejaGnu, but native for GDB
|
|
|
|
(e.g. building on x86 a GDB that runs on ARM and running the
|
|
|
|
testsuite with a remote host).
|
|
|
|
|
|
|
|
Therefore, care must be taken to check for the right kind of remote.
|
|
|
|
Use [is_remote target] to check whether the DejaGnu target board is
|
|
|
|
remote. When what you really want to know is whether GDB is using the
|
|
|
|
remote protocol, because feature X is only available when GDB debugs
|
|
|
|
natively, check gdb_protocol instead.
|