aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/boards
AgeCommit message (Collapse)AuthorFilesLines
2019-06-18[gdb/testsuite] Use -fuse-ld=gold in fission.expTom de Vries1-1/+2
The target board fission.exp requires the gold linker (because it supports --gdb-index). When running the target board on a system where the default linker is not gold, most tests will fail to compile. Fix this by adding "-fuse-ld=gold" ( supported in gcc since version 4.8). gdb/testsuite/ChangeLog: 2019-06-18 Tom de Vries <tdevries@suse.de> * boards/fission.exp (debug_flags): Add "-fuse-ld=gold".
2019-06-18[gdb/testsuite] Break up long debug_flags line in fission.expTom de Vries1-1/+6
gdb/testsuite/ChangeLog: 2019-06-18 Tom de Vries <tdevries@suse.de> * boards/fission.exp: Break up long debug_flags line.
2019-06-11[gdb/testsuite] Add readnow.expTom de Vries1-0/+27
Add a target board to test -readnow. gdb/testsuite/ChangeLog: 2019-06-11 Tom de Vries <tdevries@suse.de> * boards/readnow.exp: New file.
2019-05-04[gdb/testsuite] Add cc-with-debug-names.expTom de Vries1-0/+26
Add a target board that makes it easy to run the test suite with a .debug_names section added to executables. gdb/ChangeLog: 2019-05-04 Tom de Vries <tdevries@suse.de> * contrib/cc-with-tweaks.sh: Support -n arg. gdb/testsuite/ChangeLog: 2019-05-04 Tom de Vries <tdevries@suse.de> * boards/cc-with-debug-names.exp: New file.
2019-05-03[gdb/testsuite] Add cc-with-gdb-index.expTom de Vries1-0/+26
Add a target board cc-with-gdb-index.exp, to make it easy to run cc-with-tweaks with CC_WITH_TWEAKS_FLAGS='-i'. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2019-05-03 Tom de Vries <tdevries@suse.de> * boards/cc-with-gdb-index.exp: New file.
2019-05-01[gdb/testsuite] Fix "unable to find usable gdb" error with cc-with-tweaks.expTom de Vries1-0/+5
When running fullpath-expand.exp with target_board=dwarf4-gdb-index, we run into: ... $ make check-gdb RUNTESTFLAGS="--target_board=dwarf4-gdb-index fullpath-expand.exp" Running src/gdb/testsuite/gdb.base/fullpath-expand.exp ... gdb compile failed, cc-with-tweaks.sh: unable to find usable gdb === gdb Summary === nr of untested testcases 1 ... The same happens with fullname.exp. The dwarf4-gdb-index.exp board file includes cc-with-tweaks.exp, which uses cc-with-tweaks.sh, which calls gdb-add-index.sh. The gdb-add-index.sh script uses a gdb executable, defaulting to gdb: ... GDB=${GDB:=gdb} ... The cc-with-tweaks.sh script tries to ensure that the build gdb executable is used by gdb-add-index.sh: ... if [ -z "$GDB" ] then if [ -f ./gdb ] then GDB="./gdb -data-directory data-directory" elif [ -f ../gdb ] then GDB="../gdb -data-directory ../data-directory" elif [ -f ../../gdb ] then GDB="../../gdb -data-directory ../../data-directory" else echo "$myname: unable to find usable gdb" >&2 exit 1 fi fi ... So, if the current directory is build/gdb/testsuite, then a gdb executable build/gdb/testsuite/../gdb will be used. However, in the case of fullpath-expand.exp the test cd's into the sources: ... set saved_pwd [pwd] cd $srcdir set err [gdb_compile "${subdir}/${srcfile} ${subdir}/${srcfile2}" $binfile \ executable {debug}] cd $saved_pwd ... and cc-with-tweaks.sh generates the "unable to find usable gdb" error. The same error occurs if we use --target_board=cc-with-dwz instead (only in this case we actually don't need gdb, we just need the GDB variable to be set in cc-with-tweaks.sh, which arguably is a bug in cc-with-tweaks.sh). Fix both errors in cc-with-tweaks.exp by generating a gdb script gdb.sh using $GDB, $GDBFLAGS and $INTERNAL_GDBFLAGS and passing this script to cc-with-tweaks.sh by setting env(GDB). Tested on x86_64-linux for gdb.base. gdb/testsuite/ChangeLog: 2019-05-01 Tom de Vries <tdevries@suse.de> * boards/cc-with-tweaks.exp: Generate gdb.sh, and pass it in env(GDB).
2019-05-01[gdb/testsuite] Use cc-with-tweaks.exp in dwarf4-gdb-index.expTom de Vries1-20/+2
Board file dwarf4-gdb-index.exp contains all the commands from cc-with-tweaks.exp (with CC_WITH_TWEAKS_FLAGS set to "-i"). Make dwarf4-gdb-index.exp smaller by including cc-with-tweaks.exp. Tested on x86_64-linux for gdb.base. gdb/testsuite/ChangeLog: 2019-05-01 Tom de Vries <tdevries@suse.de> * boards/dwarf4-gdb-index.exp: Use cc-with-tweaks.exp.
2019-04-18[gdb/testsuite] Fix gdb.base/break-probes.exp with native-gdbserverTom de Vries1-1/+1
When running break-probes.exp with native-gdbserver, we run into: ... FAIL: gdb.base/break-probes.exp: run til our library loads (the program exited) FAIL: gdb.base/break-probes.exp: call (int) foo(23) ... due to the fact that we're trying to match: ... Inferior loaded /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base\ /break-probes/break-probes-solib.so ... using pattern: ... Inferior loaded $sysroot$binfile_lib ... which expands into: ... Inferior loaded //data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base\ /break-probes/break-probes-solib.so ... Fix by setting sysroot to "" in local-board.exp. Tested on x86_64-linux with native-gdbserver. gdb/testsuite/ChangeLog: 2019-04-18 Tom de Vries <tdevries@suse.de> PR gdb/24433 * boards/local-board.exp: Set sysroot to "".
2019-04-11[gdb/testsuite] Add cc-with-dwz.exp and cc-with-dwz-m.expTom de Vries3-0/+60
We can use CC_WITH_TWEAKS_FLAGS when cd-ing into the gdb build subdir and invoking make check: ... $ cd $objdir/gdb $ make check \ RUNTESTFLAGS='--target_board=cc-with-tweaks' \ CC_WITH_TWEAKS_FLAGS='-z' ... But when cd-ing into the top-level build dir and invoking make check-gdb instead: ... $ cd $objdir $ make check-gdb \ RUNTESTFLAGS='--target_board=cc-with-tweaks' \ CC_WITH_TWEAKS_FLAGS='-z' ... using CC_WITH_TWEAKS_FLAGS has no effect, because CC_WITH_TWEAKS_FLAGS is not passed down from the top level Makefile. Add cc-with-dwz.exp and cc-with-dwz-m.exp, that don't require CC_WITH_TWEAKS_FLAGS to be set in the make invocation, allowing us to run these test configurations from the toplevel build dir: ... $ cd $objdir $ make check-gdb \ RUNTESTFLAGS='--target_board=cc-with-dwz' ... Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2019-04-11 Tom de Vries <tdevries@suse.de> * boards/cc-with-dwz-m.exp: New file. * boards/cc-with-dwz.exp: New file. * boards/cc-with-tweaks.exp: Note that check-gdb doesn't work.
2019-03-28Testsuite: set sysroot when using gdbserverAlan Hayward1-0/+3
When testing using native-gdbserver and native-extended-gdbserver, the sysroot is not set. This results in a warning from GDB and files are sent via the remote protocol, which can be slow. On Ubuntu 18.04 (unlike most distros) the debug versions of the standard libraries are included by default in /usr/lib/debug/. These file reads are causing a complete native-gdbserver run on the AArch64 buildbot slave to timeout after 2.5 hours. This is also causing the builds to back up on the slave. The solution is to ensure the sysroot is set to / for all local boards. This drastically reduces the time of a test. For example, gdb.base/sigall.exp drops from 23 seconds to 4 seconds. A full native-gdbserver run on the AArch64 slave now takes 8 minutes. gdb/testsuite/ChangeLog: * boards/local-board.exp: set sysroot to /.
2019-01-01Update copyright year range in all GDB files.Joel Brobecker16-16/+16
This commit applies all changes made after running the gdb/copyright.py script. Note that one file was flagged by the script, due to an invalid copyright header (gdb/unittests/basic_string_view/element_access/char/empty.cc). As the file was copied from GCC's libstdc++-v3 testsuite, this commit leaves this file untouched for the time being; a patch to fix the header was sent to gcc-patches first. gdb/ChangeLog: Update copyright year range in all GDB files.
2018-07-11Implement IPv6 support for GDB/gdbserverSergio Durigan Junior2-3/+0
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-06-20testsuite: Fix cc-with-tweaks.sh being executed in the wrong shellSimon Marchi3-6/+6
The cc-with-tweaks.sh script needs to be executed with bash. When trying to run this: make check RUNTESTFLAGS="--target_board=dwarf4-gdb-index" TESTS="gdb.base/return.exp" I get: gdb compile failed, /home/emaisin/src/binutils-gdb/gdb/contrib/cc-with-tweaks.sh: 174: /home/emaisin/src/binutils-gdb/gdb/contrib/cc-with-tweaks.sh: Bad substitution The reason is that the board files execute cc-with-tweaks.sh using /bin/sh, which points to dash on my machine. Remove the /bin/sh part and let the shebang choose the right interpreter. gdb/testsuite/ChangeLog: * boards/cc-with-tweaks.exp: Don't call cc-with-tweaks.sh through /bin/sh. * boards/dwarf4-gdb-index.exp: Likewise. * boards/fission-dwp.exp: Likewise.
2018-03-08remote-stdio-gdbserver: Pass "target" to remote_exec to delete fileSimon Marchi1-1/+1
As described here https://sourceware.org/bugzilla/show_bug.cgi?id=22841 there seems to be situations where the remote-stdio-gdbserver board fails to delete the uploaded binary file. Passing "target" fixes the issue for Christian who reported the bug. I did not experience this problem, but passing "target" to remote_exec still works for me, so I'm fine with changing it. Any objection? gdb/testsuite/ChangeLog: PR gdb/22841 * boards/remote-stdio-gdbserver.exp (${board}_file): Pass "target" to remote_exec.
2018-03-08Don't redefine upload/download/file in gdbserver-baseSimon Marchi1-22/+0
Before patch Make native gdbserver boards no longer be "remote" (in DejaGnu terms) 739b3f1d8ff7072dcc66240c25b026c6433bda1a the local gdbserver boards (except native-extended-gdbserver...) were considered as remote by DejaGNU. To avoid DejaGNU trying to use ssh/scp to download the files to the target (which is actually local), the gdbserver-base.exp file defined some _download, _upload and _file board operations to override the default behavior, and instead just use local operations. The same patch also changed remote-stdio-gdbserver.exp to make it inherit from gdbserver-base.exp. Since then, this board (which is actually remote) uses the overrides with local file operations. As a result, files are never actually copied to the target. I think we can simply remove the overrides from gdbserver-base.exp. Because all boards should be properly considered local or remote by DejaGNU, it should by default use the right method for transferring files. gdb/testsuite/ChangeLog: PR gdb/22841 * boards/gdbserver-base.exp (${board}_file, ${board}_download, ${board}_upload): Remove.
2018-01-02Update copyright year range in all GDB filesJoel Brobecker16-16/+16
gdb/ChangeLog: Update copyright year range in all GDB files
2017-11-30Use boards/local-board.exp moreSimon Marchi4-16/+6
local-board.exp was introduced recently, containing the code required to force the gdbserver boards to be non-remote (from the DejaGNU point of view). Other board files use the same trick of forcing isremote to 0. Instead of doing it by hand in each file, include local-board.exp. gdb/testsuite/ChangeLog: * boards/cc-with-tweaks.exp: Include local-board.exp instead of setting isremote by hand. * boards/dwarf4-gdb-index.exp: Likewise. * boards/fission.exp: Likewise. * boards/stabs.exp: Likewise.
2017-10-17Really make the native-stdio-gdbserver board non-remotePedro Alves1-0/+1
I've noticed now that due to a last-minute change, commit 739b3f1d8ff7 ("Make native gdbserver boards no longer be "remote" (in DejaGnu terms)") managed to miss loading "local-board" in the native-stdio-gdbserver board... gdb/testsuite/ChangeLog: 2017-10-17 Pedro Alves <palves@redhat.com> * boards/native-stdio-gdbserver.exp: Load "local-board".
2017-10-16Make native gdbserver boards no longer be "remote" (in DejaGnu terms)Pedro Alves6-124/+89
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-13Eliminate is_remote check in gdb.base/scope.expPedro Alves1-8/+34
This commit makes --target_board=native-gdbserver (and in principle all other is_remote boards) pass all the same gdb.base/scope.exp tests as native testing. I first wrote the gdb.base/scope.exp change described in the ChangeLog below and in the new comments in the patch, knowing that gdb_file_cmd was the right thing to use here. However, that revealed that the native-extended-gdbserver board should be overriding gdb_file_cmd+gdb_reload instead of gdb_load, as is hinted at by the comments on top of the default implementations in testsuite/lib/gdb.exp, because otherwise a gdb_run_cmd after gdb_file_cmd misses setting "set remote exec-file". However, if we do that and remove gdb_load, then we regress gdb.base/dbx.exp, so for now keep the gdb_load override as well. gdb/testsuite/ChangeLog: 2017-10-13 Pedro Alves <palves@redhat.com> * gdb.base/scope.exp: Use build_executable + clean_restart + gdb_file_cmd instead of prepare_for_testing and no longer skip "before run" tests on is_remote target boards. Update comments. * boards/native-extended-gdbserver.exp (extended_gdbserver_load_last_file): New, factored out from ... (gdb_load): ... this. Move further below and add comment. (extended_gdbserver_gdb_file_cmd, gdb_file_cmd, gdb_reload): New.
2017-01-01update copyright year range in GDB filesJoel Brobecker14-14/+14
This applies the second part of GDB's End of Year Procedure, which updates the copyright year range in all of GDB's files. gdb/ChangeLog: Update copyright year range in all GDB files.
2016-09-22Use gdbserver-base in remote-gdbserver-on-localhost.expYao Qi2-37/+2
This patch is to make remote-gdbserver-on-localhost.exp use gdbserver-base and remove duplicated code. gdb/testsuite: 2016-09-22 Yao Qi <yao.qi@linaro.org> * boards/gdbserver-base.exp (gdb_server_prog): Set the absolute path. * boards/remote-gdbserver-on-localhost.exp: Use gdbserver-base. Remove duplication.
2016-04-13gdbserver-base.exp: Copy file to standard output directory in ${board}_downloadSimon Marchi1-1/+8
gdbserver-base.exp is used as the base for both native-gdbserver.exp and native-extended-gdbserver.exp. (Despite its name, it should really be considered as a "local-gdbserver-base", as it's not really appropriate to implement a remote gdbserver board.) Currently, the _download procedure is implemented as a no-op (it returns the source file path). Because of the SONAME change, The fast tracepoint tests now require the executable and the IPA (libinproctrace.so) to be located in the same directory (see [1]). When using the native-gdbserver board, because _download returns the original file path, the executable does not end up in the same directory as the library, and it fails to execute. In more general terms, with the recent changes, the testsuite now assumes that when it does ${board}_download <source path 1> <destination path 1> ${board}_download <source path 2> <destination path 2> where the destination paths are relative (generally just the file name), both files will end up in the same base directory. That assumption does not hold for the current implementation in gdbserver-base.exp. The proper fix would be to make native-gdbserver non-remote, so that gdb_remote_download would not call DejaGnu's remote_download (see [2]). We could then get rid of ${board}_download in gdbserver-base.exp. However, that will likely take some time to complete. In the mean time, in order to make the fast tracepoint tests pass, we can simply copy the file to the standard output directory. Basically, it just mimics what gdb_remote_download would do if the board wasn't flagged as remote. Note that I missed these failures originally because I had a libinproctrace.so in /usr/local/lib. So, even though libinproctrace.so wasn't copied to the test output directory, it did find the one in /usr/local/lib. It would be nice to find a way to protect against this, as it could easily happen again... Regtested with unix, native-gdbserver and native-extended-gdbserver, and didn't see anything notable, except the ftrace tests now passing for native-gdbserver. [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=6e774b13c3b81ac2599812adf058796948ce7e95 [2] https://sourceware.org/ml/gdb-patches/2016-04/msg00112.html gdb/testsuite/ChangeLog: * boards/gdbserver-base.exp (${board}_download): Copy source file to standard output directory.
2016-01-01GDB copyright headers update after running GDB's copyright.py script.Joel Brobecker14-14/+14
gdb/ChangeLog: Update year range in copyright notice of all files.
2015-07-29Don't set gdb,noinferiorio on gdbserver boardsPedro Alves1-3/+0
As all tests that check gdb,noinferiorio have been adjusted to expect inferior output with "-i $inferior_spawn_id", we can remove this now, and thus enable those tests against gdbserver. gdb/testsuite/ChangeLog: 2015-07-29 Pedro Alves <palves@redhat.com> * boards/gdbserver-base.exp: Don't set gdb,noinferiorio.
2015-06-22Add comments on using board file remote-gdbserver-on-localhost.expYao Qi1-0/+3
This commit is to add comments on using this board file and the requirements on localhost. gdb/testsuite: 2015-06-22 Yao Qi <yao.qi@linaro.org> * boards/remote-gdbserver-on-localhost.exp: Add comments.
2015-04-24A new board file remote-gdbserver-on-localhost.expYao Qi1-0/+79
This patch is to add a new board file that does real remote gdbserver testing on localhost. This board file can be used to reproduce PR 18208. gdb/testsuite 2015-04-24 Yao Qi <yao.qi@linaro.org> * boards/remote-gdbserver-on-localhost.exp: New file.
2015-04-16Fix {mi-tracepoint-changed, mi-tsv-changed}.exp with native-extended-gdbserverPedro Alves1-2/+7
Fixes: -FAIL: gdb.trace/mi-tracepoint-changed.exp: reconnect: break-info 1 +PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: tracepoint created +PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: tracepoint on marker is installed +PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: break-info 1 -FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created -FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created +PASS: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created +PASS: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created These tests do something like this: #0 - start gdb/gdbserver normally #1 - setup some things in the debug session #2 - disconnect from gdbserver #3 - restart gdb #4 - reconnect to gdbserver The problem is that the native-extended-gdbserver board always spawns a new gdbserver instance in #3 (and has gdb connect to that). So when the test gets to #4, it connects to that new instance instead of the old one: (gdb) spawn ../gdbserver/gdbserver --multi :2354 Listening on port 2354 target extended-remote localhost:2354 Remote debugging using localhost:2354 ... spawn ../gdbserver/gdbserver --multi :2355 Listening on port 2355 47-target-select extended-remote localhost:2355 =tsv-created,name="trace_timestamp",initial="0"\n 47^connected (gdb) ... 47-target-select extended-remote localhost:2355 47^connected (gdb) FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created testsuite/ChangeLog: 2015-04-16 Pedro Alves <palves@redhat.com> * boards/native-extended-gdbserver.exp (mi_gdb_start): Don't start a new gdbserver if gdbserver_reconnect_p is set.
2015-02-04Fix '--target_board=native-extended-gdbserver/-m32'Pedro Alves1-1/+3
Running the testsuite with the native-extended-gdbserver.exp board and passing a variant spec, like make check RUNTESTFLAGS="--target_board=native-extended-gdbserver/-m32" results in dejagnu trying to open a rsh connection to "native-extended-gdbserver", which of course is wrong. The point of this board is running things locally. The issue is that the native-extended-gdbserver board does not clear the "isremote" flag properly. Reported by Sergio at: https://sourceware.org/ml/gdb-patches/2015-02/msg00067.html testsuite/ 2015-02-04 Pedro Alves <palves@redhat.com> * boards/native-extended-gdbserver.exp: Remove any target variant specifications from the board name before clearing the isremote flag from board_info.
2015-01-01Update year range in copyright notice of all files owned by the GDB project.Joel Brobecker13-13/+13
gdb/ChangeLog: Update year range in copyright notice of all files.
2014-12-16boards/stabs.exp: New file.Doug Evans1-0/+45
gdb/ChangeLog: * boards/stabs.exp: New file.
2014-09-16Another board file for remote hostYao Qi1-0/+85
In the recent review to my patch about copying files to remote host, we find that we need a board file which is more closely mapped real remote host testing to improve coverage. With the board file local-remote-host-native.exp, DejaGNU copies files to $build/gdb/testsuite/remote-host to emulate the effect of remote host. Is it OK? gdb/testsuite: 2014-09-16 Yao Qi <yao@codesourcery.com> * boards/local-remote-host-native.exp: New file.
2014-08-18boards/fission.exp: Explicitly pass -ggnu-pubnames for clang.David Blaikie1-1/+3
* boards/fission.exp: Explicitly pass -ggnu-pubnames for clang.
2014-05-21Allow making GDB not automatically connect to the native target.Pedro Alves1-0/+2
Sometimes it's useful to be able to disable the automatic connection to the native target. E.g., sometimes GDB disconnects from the extended-remote target I was debugging, without me noticing it, and then I do "run". That starts the program locally, and only after a little head scratch session do I figure out the program is running locally instead of remotely as intended. Same thing with "attach", "info os", etc. With the patch, we now can have this instead: (gdb) set auto-connect-native-target off (gdb) target extended-remote :9999 ... *gdb disconnects* (gdb) run Don't know how to run. Try "help target". To still be able to connect to the native target with auto-connect-native-target set to off, I've made "target native" work instead of erroring out as today. Before: (gdb) target native Use the "run" command to start a native process. After: (gdb) target native Done. Use the "run" command to start a process. (gdb) maint print target-stack The current target stack is: - native (Native process) - exec (Local exec file) - None (None) (gdb) run Starting program: ./a.out ... I've also wanted this for the testsuite, when running against the native-extended-gdbserver.exp board (runs against gdbserver in extended-remote mode). With a non-native-target board, it's always a bug to launch a program with the native target. Turns out we still have one such case this patch catches: (gdb) break main Breakpoint 1 at 0x4009e5: file ../../../src/gdb/testsuite/gdb.base/coremaker.c, line 138. (gdb) run Don't know how to run. Try "help target". (gdb) FAIL: gdb.base/corefile.exp: run: with core On the patch itself, probably the least obvious bit is the need to go through all targets, and move the unpush_target call to after the generic_mourn_inferior call instead of before. This is what inf-ptrace.c does too, ever since multi-process support was added. The reason inf-ptrace.c does things in that order is that in the current multi-process/single-target model, we shouldn't unpush the target if there are still other live inferiors being debugged. The check for that is "have_inferiors ()" (a misnomer nowadays...), which does: have_inferiors (void) { for (inf = inferior_list; inf; inf = inf->next) if (inf->pid != 0) return 1; It's generic_mourn_inferior that ends up clearing inf->pid, so we need to call it before the have_inferiors check. To make all native targets behave the same WRT to explicit "target native", I've added an inf_child_maybe_unpush_target function that targets call instead of calling unpush_target directly, and as that includes the have_inferiors check, I needed to adjust the targets. Tested on x86_64 Fedora 20, native, and also with the extended-gdbserver board. Confirmed a cross build of djgpp gdb still builds. Smoke tested a cross build of Windows gdb under Wine. Untested otherwise. gdb/ 2014-05-21 Pedro Alves <palves@redhat.com> * inf-child.c (inf_child_ops, inf_child_explicitly_opened): New globals. (inf_child_open_target): New function. (inf_child_open): Use inf_child_open_target to push the target instead of erroring out. (inf_child_disconnect, inf_child_close) (inf_child_maybe_unpush_target): New functions. (inf_child_target): Install inf_child_disconnect and inf_child_close. Store a pointer to the returned object. * inf-child.h (inf_child_open_target, inf_child_maybe_unpush): New declarations. * target.c (auto_connect_native_target): New global. (show_default_run_target): New function. (find_default_run_target): Return NULL if automatically connecting to the native target is disabled. (_initialize_target): Install set/show auto-connect-native-target. * NEWS: Mention "set auto-connect-native-target", and "target native". * linux-nat.c (super_close): New global. (linux_nat_close): Call super_close. (linux_nat_add_target): Store a pointer to the base class's to_close method. * inf-ptrace.c (inf_ptrace_mourn_inferior, inf_ptrace_detach): Use inf_child_maybe_unpush. * inf-ttrace.c (inf_ttrace_him): Don't push the target if it is already pushed. (inf_ttrace_mourn_inferior): Only unpush the target after mourning the inferior. Use inf_child_maybe_unpush_target. (inf_ttrace_attach): Don't push the target if it is already pushed. (inf_ttrace_detach): Use inf_child_maybe_unpush_target. * darwin-nat.c (darwin_mourn_inferior): Only unpush the target after mourning the inferior. Use inf_child_maybe_unpush_target. (darwin_attach_pid): Don't push the target if it is already pushed. * gnu-nat.c (gnu_mourn_inferior): Only unpush the target after mourning the inferior. Use inf_child_maybe_unpush_target. (gnu_detach): Use inf_child_maybe_unpush_target. * go32-nat.c (go32_create_inferior): Don't push the target if it is already pushed. (go32_mourn_inferior): Use inf_child_maybe_unpush_target. * nto-procfs.c (procfs_is_nto_target): Adjust comment. (procfs_open): Rename to ... (procfs_open_1): ... this. Add target_ops parameter. Adjust comments. Can target_preopen before changing node. Call inf_child_open_target to push the target explicitly. (procfs_attach): Don't push the target if it is already pushed. (procfs_detach): Use inf_child_maybe_unpush_target. (procfs_create_inferior): Don't push the target if it is already pushed. (nto_native_ops): New global. (procfs_open): Reimplement. (procfs_native_open): New function. (init_procfs_targets): Install procfs_native_open as to_open of "target native". Store a pointer to the "native" target in nto_native_ops. * procfs.c (procfs_attach): Don't push the target if it is already pushed. (procfs_detach): Use inf_child_maybe_unpush_target. (procfs_mourn_inferior): Only unpush the target after mourning the inferior. Use inf_child_maybe_unpush_target. (procfs_init_inferior): Don't push the target if it is already pushed. * windows-nat.c (do_initial_windows_stuff): Don't push the target if it is already pushed. (windows_detach): Use inf_child_maybe_unpush_target. (windows_mourn_inferior): Only unpush the target after mourning the inferior. Use inf_child_maybe_unpush_target. gdb/doc/ 2014-05-21 Pedro Alves <palves@redhat.com> * gdb.texinfo (Starting): Document "set/show auto-connect-native-target". (Target Commands): Document "target native". gdb/testsuite/ 2014-05-21 Pedro Alves <palves@redhat.com> * boards/gdbserver-base.exp (GDBFLAGS): Set to "set auto-connect-native-target off". * gdb.base/auto-connect-native-target.c: New file. * gdb.base/auto-connect-native-target.exp: New file.
2014-05-14Overwrite ${board}_file in local-remote-hostYao Qi1-0/+7
After I run test like this, $ make check RUNTESTFLAGS='--host_board=local-remote-host dw2-basic.exp' gdb.dwarf2/file1.txt in source tree was removed. In some gdb.dwarf2/*.exp, file1.txt is copied to host and then removed at the end. However, in local-remote-host-notty.exp, ${board}_download doesn't copy the file but return the absolute path of the src file. 'remote_file host delete' at the end will remove the file in source tree. This patch is to overwrite ${board}_file, and specially make "delete" option do nothing. This approach is used in gdbserver-base.exp and remote-stdio-gdbserver.exp too. gdb/testsuite: 2014-05-14 Yao Qi <yao@codesourcery.com> * boards/local-remote-host-notty.exp (${board}_file): New proc.
2014-05-02gdb_load: Fix latent bugsPedro Alves1-1/+2
In a test I was writting, I needed a procedure that would connect to the target, and do "load", or equivalent. Years ago, boards would override gdb_load to implement that. Then gdb_reload was added, and gdb_load was relaxed to allow boards avoid the spawing and connecting to the target. This sped up gdbserver testing. See https://www.sourceware.org/ml/gdb-patches/2007-02/msg00318.html. To actually spawn the target and load the executable on the target side, gdb_reload was born: # gdb_reload -- load a file into the target. Called before "running", # either the first time or after already starting the program once, # for remote targets. Most files that override gdb_load should now # override this instead. proc gdb_reload { } { # For the benefit of existing configurations, default to gdb_load. # Specifying no file defaults to the executable currently being # debugged. return [gdb_load ""] } Note the comment about specifying no file. Indeed looking at config/sid.exp, or config/monitor.exp, we see examples of that. However, the default gdb_load itself doesn't handle the case of no file specified. When passed no file, it just calls gdb_file_cmd with no file either, which ends up invocing the "file" command with no argument, which means unloading the file and its symbols... That means calling gdb_reload when testing against native targets is broken. We don't see that today because the only call to gdb_reload that exists today is guarded by target_info exists gdb,do_reload_on_run. The native-extended-gdbserver.exp board is likewise broken here. When [gdb_load ""] is called, the board sets the remote exec-file to "" ... Tested on x86_64 Fedora 17, native, remote gdbserver and extended-remote gdbserver. testsuite/ 2014-05-01 Pedro Alves <palves@redhat.com> * lib/gdb.exp (gdb_load): Extend comment. Skip calling gdb_file_cmd if no file is specified. * boards/native-extended-gdbserver.exp (gdb_load): Use the last_loaded_file to set the remote exec-file.
2014-05-01New testsuite/boards/local-remote-host.exp board, now with editing onPedro Alves1-0/+32
This adds a variant of local-remote-host-notty.exp that forces pseudo-tty allocation, so that readline/editing is enabled. $ ssh localhost gdb -q (gdb) show editing Editing of command lines as they are typed is off. (gdb) vs: $ ssh -t localhost gdb -q (gdb) show editing Editing of command lines as they are typed is on. We now get, e.g.: Running ../../../src/gdb/testsuite/gdb.base/filesym.exp ... PASS: gdb.base/filesym.exp: complete on "filesy" PASS: gdb.base/filesym.exp: completion list for "filesym" PASS: gdb.base/filesym.exp: set breakpoint at filesym gdb/testsuite/ 2014-05-01 Pedro Alves <palves@redhat.com> * boards/local-remote-host.exp: New file.
2014-05-01Rename testsuite/boards/local-remote-host.exp -> ↵Pedro Alves1-0/+0
testsuite/boards/local-remote-host-notty.exp When testing with this board, stdin is not a tty, and so readline/editing is disabled: $ ssh localhost gdb -q (gdb) show editing Editing of command lines as they are typed is off. (gdb) Rename the file, to make room for a version of this board that forces a pseudo-tty. gdb/testsuite/ 2014-05-01 Pedro Alves <palves@redhat.com> * boards/local-remote-host.exp: Rename to ... * boards/local-remote-host-notty.exp: ... this.
2014-04-16Fix wrapper.exp testcase with stdio gdbserver.Doug Evans2-76/+16
* lib/gdbserver-support.exp (gdbserver_default_get_remote_address): Add comment. (gdbserver_default_get_comm_port): New function. (gdbserver_start): Check if board file provided "gdbserver,get_comm_port" and use it if so. * boards/native-stdio-gdbserver.exp (sockethost): Set to "". (gdb,socketport): Set to "stdio". (gdbserver,get_comm_port): Set to ${board}_get_comm_port. (stdio_gdbserver_template): Delete. (${board}_get_remote_address): Update. (${board}_build_remote_cmd): Delete. (${board}_get_comm_port): New function. (${board}_spawn): Update. * boards/remote-stdio-gdbserver.exp (${board}_build_remote_cmd): Delete. (${board}_get_remote_address): Update. (${board}_get_comm_port): New function.
2014-01-01Update Copyright year range in all files maintained by GDB.Joel Brobecker10-10/+10
2013-10-02Teach the testsuite that GDBserver reliably reports program exits.Pedro Alves2-0/+2
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-08-292013-08-29 Sterling Augustine <saugustine@google.com>Sterling Augustine1-6/+9
* boards/remote-stdio-gdbserver.exp: Set rcp_prog and rsh_prog in new conditional. Move use of REMOTE_PORTNUM into said conditional.
2013-08-14 * boards/fission.exp: Add -fdebug-types-section to debug_flags.Doug Evans1-1/+1
2013-07-24 * boards/native-stdio-gdbserver.exp (${board}_build_remote_cmd): PassDoug Evans1-1/+1
"--" to switch.
2013-07-07gdb/testsuite/Yao Qi4-91/+53
* boards/native-gdbserver.exp: Move invoke of process_multilib_options to gdbserver-base.exp. Move set_board_info 'compiler', 'gdb,noinferiorio', 'gdb,nofileio', 'gdb_server_prog' and 'gdb,predefined_tsv' to gdbserver-base.exp. Move proc ${board}_download, ${board}_upload and ${board}_file to gdbserver-base.exp. * boards/native-extended-gdbserver.exp: Likewise. * boards/native-stdio-gdbserver.exp: Likewise. * boards/gdbserver-base.exp: New file.
2013-07-05gdb/testsuite/Yao Qi4-24/+0
* boards/local-remote-host.exp: Remove obsolete comments. * boards/native-extended-gdbserver.exp: Likewise. * boards/native-gdbserver.exp: Likewise. * boards/native-stdio-gdbserver.exp: Likewise.
2013-06-25Upload tsv earlier in remote_start_remoteYao Qi3-0/+9
In extended-remote, when GDB connects the target, but target is not running, the TSVs are not uploaded. When GDB attaches to a process, the TSVs are not uploaded either. However, GDBserver has some builtin or predefined TSV to upload, such as $trace_timestamp. This bug causes $trace_timestamp is never uploaded. gdb/ 2013-06-25 Yao Qi <yao@codesourcery.com> * remote.c (remote_start_remote): Move code to upload tsv earlier. gdb/testsuite/ 2013-06-25 Yao Qi <yao@codesourcery.com> * boards/native-extended-gdbserver.exp: Set board_info 'gdb,predefined_tsv'. * boards/native-gdbserver.exp: Likewise. * boards/native-stdio-gdbserver.exp: Likewise. * gdb.server/ext-attach.exp: Load trace-support.exp. Check uploaded TSVs if target supports tracing. * gdb.trace/tsv.exp: Check uploaded TSVs if target supports tracing and target has predefined tsv. gdb/doc/ 2013-06-25 Yao Qi <yao@codesourcery.com> * gdbint.texinfo (Testsuite): Document 'gdb,predefined_tsv'.
2013-06-07Remove superfluous semicolons from testsuite throughout.Pedro Alves1-1/+1
A few months ago semicolons after "return" were removed throughout the testsuite. However, as I pointed out in review, they're unnecessary not just after "return", but pretty much after any tcl command. ';' is the command separator, and you only need it if there's another command on the same line afterwards. This patch was written by running: $ find . -name "*.exp" | xargs grep -l ";\s*$" | xargs sed -i 's/\([^#][^\s*;]*\)\s*;\s*$/\1/' and then undoing changes to comments, and lib/future.exp. Tested on x86_64 Fedora 17. gdb/testsuite/ 2013-06-07 Pedro Alves <palves@redhat.com> * boards/native-extended-gdbserver.exp: Remove semicolon. * config/arm-ice.exp: Likewise. * config/bfin.exp: Likewise. * config/cygmon.exp: Likewise. * config/h8300.exp: Likewise. * config/monitor.exp: Likewise. * config/sid.exp: Likewise. * config/sim.exp: Likewise. * config/slite.exp: Likewise. * config/vx.exp: Likewise. * gdb.arch/i386-bp_permanent.exp: Likewise. * gdb.asm/asm-source.exp: Likewise. * gdb.base/args.exp: Likewise. * gdb.base/attach-pie-misread.exp: Likewise. * gdb.base/auxv.exp: Likewise. * gdb.base/bigcore.exp: Likewise. * gdb.base/bitfields2.exp: Likewise. * gdb.base/bitfields.exp: Likewise. * gdb.base/break.exp: Likewise. * gdb.base/break-interp.exp: Likewise. * gdb.base/callfuncs.exp: Likewise. * gdb.base/call-sc.exp: Likewise. * gdb.base/commands.exp: Likewise. * gdb.base/corefile.exp: Likewise. * gdb.base/dbx.exp: Likewise. * gdb.base/ending-run.exp: Likewise. * gdb.base/exprs.exp: Likewise. * gdb.base/funcargs.exp: Likewise. * gdb.base/hbreak2.exp: Likewise. * gdb.base/huge.exp: Likewise. * gdb.base/list.exp: Likewise. * gdb.base/memattr.exp: Likewise. * gdb.base/overlays.exp: Likewise. * gdb.base/printcmds.exp: Likewise. * gdb.base/recurse.exp: Likewise. * gdb.base/remotetimeout.exp: Likewise. * gdb.base/reread.exp: Likewise. * gdb.base/savedregs.exp: Likewise. * gdb.base/scope.exp: Likewise. * gdb.base/sepdebug.exp: Likewise. * gdb.base/setshow.exp: Likewise. * gdb.base/setvar.exp: Likewise. * gdb.base/sigaltstack.exp: Likewise. * gdb.base/siginfo-addr.exp: Likewise. * gdb.base/siginfo.exp: Likewise. * gdb.base/siginfo-obj.exp: Likewise. * gdb.base/sigrepeat.exp: Likewise. * gdb.base/sigstep.exp: Likewise. * gdb.base/structs.exp: Likewise. * gdb.base/testenv.exp: Likewise. * gdb.base/twice.exp: Likewise. * gdb.base/valgrind-db-attach.exp: Likewise. * gdb.base/valgrind-infcall.exp: Likewise. * gdb.base/varargs.exp: Likewise. * gdb.base/watchpoint.exp: Likewise. * gdb.cp/gdb1355.exp: Likewise. * gdb.cp/misc.exp: Likewise. * gdb.disasm/hppa.exp: Likewise. * gdb.disasm/t01_mov.exp: Likewise. * gdb.disasm/t02_mova.exp: Likewise. * gdb.disasm/t03_add.exp: Likewise. * gdb.disasm/t04_sub.exp: Likewise. * gdb.disasm/t05_cmp.exp: Likewise. * gdb.disasm/t06_ari2.exp: Likewise. * gdb.disasm/t07_ari3.exp: Likewise. * gdb.disasm/t08_or.exp: Likewise. * gdb.disasm/t09_xor.exp: Likewise. * gdb.disasm/t10_and.exp: Likewise. * gdb.disasm/t11_logs.exp: Likewise. * gdb.disasm/t12_bit.exp: Likewise. * gdb.disasm/t13_otr.exp: Likewise. * gdb.gdb/selftest.exp: Likewise. * gdb.hp/gdb.base-hp/callfwmall.exp: Likewise. * gdb.mi/mi-reverse.exp: Likewise. * gdb.pascal/floats.exp: Likewise. * gdb.python/py-inferior.exp: Likewise. * gdb.threads/attach-into-signal.exp: Likewise. * gdb.threads/pthreads.exp: Likewise. * gdb.threads/thread_events.exp: Likewise. * gdb.threads/watchthreads.exp: Likewise. * gdb.trace/actions-changed.exp: Likewise. * gdb.trace/actions.exp: Likewise. * gdb.trace/ax.exp: Likewise. * gdb.trace/backtrace.exp: Likewise. * gdb.trace/change-loc.exp: Likewise. * gdb.trace/deltrace.exp: Likewise. * gdb.trace/disconnected-tracing.exp: Likewise. * gdb.trace/ftrace.exp: Likewise. * gdb.trace/infotrace.exp: Likewise. * gdb.trace/passc-dyn.exp: Likewise. * gdb.trace/passcount.exp: Likewise. * gdb.trace/pending.exp: Likewise. * gdb.trace/qtro.exp: Likewise. * gdb.trace/range-stepping.exp: Likewise. * gdb.trace/report.exp: Likewise. * gdb.trace/save-trace.exp: Likewise. * gdb.trace/status-stop.exp: Likewise. * gdb.trace/strace.exp: Likewise. * gdb.trace/tfile.exp: Likewise. * gdb.trace/tfind.exp: Likewise. * gdb.trace/trace-break.exp: Likewise. * gdb.trace/tracecmd.exp: Likewise. * gdb.trace/trace-mt.exp: Likewise. * gdb.trace/tspeed.exp: Likewise. * gdb.trace/tsv.exp: Likewise. * gdb.trace/while-stepping.exp: Likewise. * lib/gdb.exp: Likewise. * lib/gdbserver-support.exp: Likewise. * lib/java.exp: Likewise. * lib/mi-support.exp: Likewise. * lib/pascal.exp: Likewise. * lib/prompt.exp: Likewise. * lib/trace-support.exp: Likewise.
2013-05-24Update to load fission.exp.Doug Evans1-15/+3
2013-05-24 * boards/fission-dwp.exp: New file.Doug Evans1-0/+61