aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/boards
AgeCommit message (Collapse)AuthorFilesLines
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess28-28/+28
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2023-11-27[gdb/testsuite] Add boards/cc-with-index-cache.expTom de Vries1-0/+40
We have a target board cc-with-gdb-index that uses the gdb-add-index script to add a .gdb_index index to an exec. There is however an alternative way of adding a .gdb_index: the index-cache. Add a new target board cc-with-index-cache. This is not superfluous for two reasons: - there is functionality that gdb-add-index doesn't support, but the index-cache does: the index-cache can add an index to an exec with a .gnu_debugaltlink (note that when using the cc-with-gdb-index board this case is quietly ignored), and - using the index-cache is excercised in only a few test-cases, and having this target board extends the test coverage to the entire test suite. This is for instance relevant because the index-cache is written by a worker thread in the background, so we can check more thoroughly for data races (see PR symtab/30837). Tested on x86_64-linux. Shell script changes checked with shellcheck. Approved-By: Tom Tromey <tom@tromey.com>
2023-10-12Fix test suite failure in file-then-restart.expTom Tromey1-2/+2
Simon pointed out that the new file-then-restart.exp test fails with the extended-remote target board. The problem is that the test suite doesn't use gdb_file_cmd -- which handles things like "set remote exec-file". This patch changes gdb_file_cmd to make the "kill" command optional, and then switches the test case to use it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30933 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-28[gdb/testsuite] Fix local-remote-host-native.exp for gdb.server testsTom de Vries1-1/+5
When running test-case gdb.server/stop-reply-no-thread-multi.exp with host+target board local-remote-host-native, I run into a time-out: ... (gdb) PASS: gdb.server/stop-reply-no-thread-multi.exp: target-non-stop=off: \ to_disable=: disconnect builtin_spawn /usr/bin/ssh -t -l vries 127.0.0.1 gdbserver --once \ localhost:2346 stop-reply-no-thread-multi^M Process stop-reply-no-thread-multi created; pid = 32600^M Listening on port 2346^M set remote threads-packet off^M FAIL: gdb.server/stop-reply-no-thread-multi.exp: target-non-stop=off: \ to_disable=: set remote threads-packet off (timeout) ... This is due to this line in ${board}_spawn: ... set board_info($board,fileid) $spawn_id ... We have the following series of events: - gdb is spawned, setting fileid - a few gdb commands (set height etc) are send using fileid, arrive at gdb and are successful - gdbserver is spawned, overwriting fileid - the next gdb command is sent using fileid, so it's send to gdbserver instead of gdb, and we run into the timeout. There is some notion of current gdb, tracked in both gdb_spawn_id and fileid of the host board (see switch_gdb_spawn_id). And because the host and target board are the same, spawning something on the target overwrites the fileid on host, and consequently the current gdb. Fix this by only setting fileid when spawning gdb. Tested on x86_64-linux. Now gdb.server/*.exp passes for host+target board local-remote-host-native, except for file-transfer.exp. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29734
2023-03-21[gdb/testsuite] Check remote_exec results in board filesTom de Vries2-23/+36
Make sure the result of each remote_exec in gdb/testsuite/boards/*.exp is checked. Tested on x86_64-linux.
2023-03-21[gdb/testsuite] Add missing quote in remote-gdbserver-on-localhost.expTom de Vries1-1/+1
In a recent commit I forgot to add a double quote before chmod here: ... remote_exec build $rsh_cmd chmod go-rx ." ... Fix it by adding the missing double quote.
2023-03-21[gdb/testsuite] Remove ${board}_file from remote-stdio-gdbserver.expTom de Vries1-8/+0
Looking at the implementation of ${board}_file in remote-stdio-gdbserver.exp, I don't see a relevant difference with the implementation of standard_file in dejagnu. Simplify the board by removing ${board}_file. Tested on x86_64-linux, by running gdb.testsuite/board-sanity.exp.
2023-03-21[gdb/testsuite] Use localhost instead of 127.0.0.1 for boardsTom de Vries2-4/+4
Some boards in gdb/testsuite/boards use the hardcoded ipv4 address "127.0.0.1". Use instead "localhost". Tested on x86_64-linux.
2023-03-21[gdb/testsuite] Set remotedir in local-remote-host-native.expTom de Vries1-0/+25
In commit ff581559f9d ("[gdb/testsuite] Add gdb.testsuite/board-sanity.exp") I removed handling of HOST_DIR in local-remote-host-native.exp to fix FAILs in test-case gdb.testsuite/board-sanity.exp. Reintroduce handling of HOST_DIR using remotedir, now that using remotedir for a host board no longer make compilation fail due to commit 80d6c79866f ("[gdb/testsuite] Handle remotedir in remote_upload"). This fixes an XFAIL in gdb.testsuite/board-sanity.exp, introduced in commit 3741934fdb0 ("[gdb/testsuite] Set remotedir by default in some boards"). Tested on x86_64-linux.
2023-03-17[gdb/testsuite] Handle REMOTE_HOST_USERNAME in local-remote-hostTom de Vries1-3/+24
Handle REMOTE_HOST_USERNAME in local-remote-host, similar to how that's done for REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost. This helps to keep the home dir clean. Since the setup makes $build/gdb/testsuite on build unreadable for the remote host, we run into permission problems for GDB and the data-directory, so fix this (as was done for gdbserver in gdbserver-base.exp) using file normalize. Tested on x86_64-linux.
2023-03-17[gdb/testsuite] Set remotedir by default in some boardsTom de Vries2-16/+45
When doing a gdb_simple_compile, and downloading the resulting exec $obj to target the result $target_obj may be a relative file path, which may give problems when trying to do: ... remote_exec target $target_obj ... Fix/workaround this on some target boards by setting remotedir by default, and add a corresponding test in gdb.testsuite/board-sanity.exp. This doesn't work for host/target board local-remote-host-native, so xfail this. Tested on x86_64-linux.
2023-03-14[gdb/testsuite] Add gdb.testsuite/board-sanity.expTom de Vries3-42/+2
Add a test-case that tests the sanity of target/host boards. It contains a number of tests related to remote file manipulation, exercising: - remote_upload - remote_download - remote_file exists - remote_file delete which check that these work together as expected. Tested on x86_64-linux, with all relevant gdb/testsuite/boards/*.exp boards. For target board remote-stdio-gdbserver.exp, this revealed a trivial problem with the return value of proc ${board}_file for delete, so fix this. The test-case shows that the proc ${board}_download in local-remote-host-native.exp is broken, so remove it. Likewise for board local-remote-host.exp, so remove proc ${board}_download and associated ${board}_file. Tested on x86_64-linux.
2023-03-09[gdb/testsuite] Fix gdbserver path in remote-stdio-gdbserver.expTom de Vries1-3/+1
With test-case gdb.server/unittest.exp and target board remote-stdio-gdbserver I run into: ... (gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost /usr/bin/gdbserver \ --selftest^M Selftests have been disabled for this build.^M UNSUPPORTED: gdb.server/unittest.exp: unit tests ... due to using the system gdbserver /usr/bin/gdbserver rather than the one from the build. Fix this by removing the hard-coding of /usr/bin/gdbserver in remote-stdio-gdbserver, allowing find_gdbserver to do its work, such that we have instead: ... (gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost \ /data/vries/gdb/leap-15-4/build/gdbserver/gdbserver --selftest^M Running selftest remote_memory_tagging.^M Ran 1 unit tests, 0 failed^M Connection to localhost closed.^M^M PASS: gdb.server/unittest.exp: unit tests ... Tested on x86_64-linux.
2023-03-07[gdb/testsuite] Fix gdb.base/signals-state-child.exp for ↵Tom de Vries1-0/+21
remote-gdbserver-on-localhost With test-case gdb.base/signals-state-child.exp on target board remote-gdbserver-on-localhost I run into: ... builtin_spawn /usr/bin/ssh -t -l remote-target localhost \ $outputs/gdb.base/signals-state-child/signals-state-child-standalone^M bash: $outputs/gdb.base/signals-state-child/signals-state-child-standalone: \ Permission denied^M Connection to localhost closed.^M^M FAIL: gdb.base/signals-state-child.exp: collect standalone signals state ... The problem is that we're trying to run an executable on the target board using a host path. After fixing this by downloading the exec to the target board, we run into: ... builtin_spawn /usr/bin/ssh -t -l remote-target localhost \ signals-state-child-standalone^M bash: signals-state-child-standalone: command not found^M Connection to localhost closed.^M^M FAIL: gdb.base/signals-state-child.exp: collect standalone signals state ... Fix this by using an absolute path name for the exec on the target board. The dejagnu proc standard_file does not support op == "absolute" for target boards, so add an implementation in remote-gdbserver-on-localhost.exp. Also: - fix a PATH-in-test-name issue - cleanup gdb.txt and standalone.txt on target board Tested on x86_64-linux.
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker27-27/+27
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2022-11-28gdb/testsuite: remove use of then keyword from library filesAndrew Burgess1-2/+2
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's still a bunch of places in the testsuite where we make use of the 'then' keyword, and sometimes these get copies into new tests, which just spreads poor practice. This commit removes all use of the 'then' keyword from the testsuite library files (in boards/, config/, and lib/). Previous commits have removed all uses of the 'then' keyword from the test script files, this commit just cleans up the library files. There should be no changes in what is tested after this commit.
2022-11-15[gdb/testsuite] Normalize gdbserver path nameTom de Vries2-5/+4
Currently for the target board remote-gdbserver-on-localhost we use the gdbserver file on build, using a file name which includes "/../". Fix this by using a normalized file name instead. This allows us to be more restrictive about which files REMOTE_TARGET_USERNAME can access: ... - remote_exec build "chmod go-rx $objdir/outputs" + remote_exec build "chmod go-rx $objdir" ... Tested on x86_64-linux.
2022-11-15[gdb/testsuite] Add REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.expTom de Vries1-2/+27
As reported here ( https://sourceware.org/pipermail/gdb-patches/2022-October/193147.html ) a number of test-cases fails with a remote target setup, for instance test-case gdb.base/print-file-var.exp. So, why don't we see these fails with our remote target boards in gdb/testsuite/boards, say remote-gdbserver-on-localhost.exp? The problem is that the target board uses the same machine and user for both (by-definition-local) build and remote target, and when using absolute pathnames to refer to files on build, we can access those files on target, which in a real remote target setup wouldn't be the case: we'd have to download them to target first, and then the filename would also be different. For aforementioned test-case, this happens when the name of a shared library is passed as absolute file name to gcc: ... gcc ... -DSHLIB_NAME="$outputs/gdb.base/print-file-var/\ print-file-var-lib2-hidden0-dlopen1-version_id_main0_c.so" ... Make these problems visible with remote-gdbserver-on-localhost.exp by adding an option to specify a test account (still on the same machine) using REMOTE_TARGET_USERNAME. We make sure by restricting file permissions, that the test account cannot see the build files on the $USER account, and that the $USER account cannot see the target files on the test account. And so we can reproduce the reported fails: ... $ cd build/gdb $ tc="gdb.base/print-file-var.exp" $ tb="--target_board remote-gdbserver-on-localhost" $ tbu="REMOTE_TARGET_USERNAME=remote-target" $ make check RUNTESTFLAGS="$tb $tbu $tc" ... FAIL: gdb.base/print-file-var.exp: lang=c: hidden=0: dlopen=1: \ version_id_main=0: continue to STOP marker ... Tested on x86_64-linux. Reported-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
2022-10-29[gdb/testsuite] Use ssh -t in remote-*.expTom de Vries2-0/+24
When running test-case gdb.server/multi-ui-errors.exp on target board remote-gdbserver-on-localhost.exp, I run into: ... (gdb) PASS: gdb.server/multi-ui-errors.exp: connect to gdbserver continue^M Continuing.^M PASS: gdb.server/multi-ui-errors.exp: continue - extra UI Remote debugging from host ::1, port 35466^M FAIL: gdb.server/multi-ui-errors.exp: ensure inferior is running ... The problem is that the target board uses ssh -T, which fails to guarantee that output from the inferior will be available. Fix this by copying proc ${board}_spawn from local-remote-host.exp, which ensures using ssh -t. [ It would be nice to define an ssh base board to get rid of the copies, but I'm not addressing that in this commit. ] Likewise for target board remote-stdio-gdbserver.exp. Tested on x86_64-linux.
2022-10-29[gdb/testsuite] Remove REMOTE_PORTNUM in remote-stdio-gdbserver.expTom de Vries1-12/+3
The usage for board remote-stdio-gdbserver.exp is advertised as: ... # bash$ make check RUNTESTFLAGS="--target_board=remote-stdio-gdbserver \ # REMOTE_USERNAME=... REMOTE_HOSTNAME=... REMOTE_PORTNUM=... \ # [REMOTE_TMPDIR=${remote_dir}] [GDBSERVER=${remote_gdbserver}]" ... but when adding REMOTE_PORTNUM=22, I run into: ... Running stop-reply-no-thread-multi.exp ... ERROR: tcl error sourcing stop-reply-no-thread-multi.exp. ERROR: couldn't execute "/usr/bin/ssh -p22": no such file or directory while executing "builtin_spawn {/usr/bin/ssh -p22} -l vries localhost {/usr/bin/gdbserver \ --once localhost:2346 \ /home/vries/gdb_versions/devel/build/gdb/testsuite/outp..." ... Fix this by simply removing REMOTE_PORTNUM. Tested on x86_64-linux.
2022-10-27[gdb/testsuite] Disable styling in host board local-remote-host-native.expTom de Vries1-0/+4
Propagate fix from commit 17c68d98f74 ("[gdb/testsuite] Disable styling in host board local-remote-host.exp") to local-remote-host-native.exp. Tested on x86_64-linux.
2022-10-18[gdb/testsuite] Update boards/READMETom de Vries1-1/+1
Update gdb/testsuite/boards/README to reflect recent commit c4c8c27263d ("[gdb/testsuite] Fix host board local-remote-host-notty.exp timeouts"), which means the board now uses a pseudo-tty, but with editing disabled.
2022-10-14[gdb/testsuite] Add boards/READMETom de Vries1-0/+88
Add a file gdb/testsuite/boards/README, to make it easier to get a high-level overview of the various boards.
2022-10-14[gdb/testsuite] Fix host board local-remote-host-notty.exp timeoutsTom de Vries2-32/+43
With test-case gdb.server/stop-reply-no-thread-multi.exp and host board local-remote-host-notty.exp we occasionally run into a silent out, due to getting: ... (gdb) kill^M (gdb) The program is not being run.^M ... instead of the expected: ... (gdb) kill^M The program is not being run.^M (gdb) ... Likewise, we occasionally run into a nonsilent timeout: ... (gdb) disconnect^M (gdb) You can't do that when your target is `exec'^M FAIL: gdb.server/stop-reply-no-thread.exp: to_disable=Tthread: t_nonstop=on: \ disconnect (timeout) ... Typically, this results in the test-case taking more than two minutes to run. The problem can be reproduced using just: ... $ ssh -l $USER 127.0.0.1 gdb -q -ex kill ... Note that ssh by default uses -T which disables pseudo-tty allocation (as opposed to -t which forces pseudo-tty allocation): ... $ ssh -l $USER 127.0.0.1 -T tty not a tty $ ssh -l $USER 127.0.0.1 -t tty /dev/pts/5 Connection to 127.0.0.1 closed. ... and according to https://stackoverflow.com/a/63241102 the behaviour we're seeing is specific to using '-T'. The related host board local-remote-host.exp does use '-t', and the only difference between the two boards mentioned is whether editing is on or off. Fix this by: - moving the content of local-remote-host-notty.exp into local-remote-host.exp - consequently, extending the copyright years in local-remote-host.exp - including local-remote-host.exp in local-remote-host-notty.exp (making local-remote-host-notty.exp use '-t') - adding -iex "set editing off" to GDBFLAGS in local-remote-host-notty.exp This results in the test-case taking just 6 seconds to run. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29669
2022-10-14[gdb/testsuite] Disable styling in host board local-remote-host.expTom de Vries1-0/+2
With test-case gdb.server/stop-reply-no-thread.exp and host board local-remote-host.exp, I run into: ... Breakpoint 1, ^[[33mmain^[[m () at ^[[32mstop-reply-no-thread.c^[[m:21^M 21 ^[[01;34mreturn^[[m ^[[35m0^[[m^[[31m;^[[m^M (gdb) FAIL: gdb.server/stop-reply-no-thread.exp: to_disable=: t_nonstop=off: \ continue to main ... The problem is that styling is enabled, and that is causing a regexp mismatch. With native, styling is disabled in default_gdb_init by doing 'setenv TERM "dumb"', but that only has effect because the build (where we execute runtest, and consequently the setenv) and the host (where we execute gdb) are the same. For this host board however, gdb executes on a remote host, and the setenv has no effect. We could try to make some generic way to set TERM on the host, but for the purposes of this test-case it seems sufficient to just add: ... set GDBFLAGS "${GDBFLAGS} -iex \"set style enabled off\"" ... so let's go with that for now. Tested on x86_64-linux.
2022-05-31gdb/testsuite: remove F77_FOR_TARGET supportNils-Christian Kempke3-7/+0
The last uses of the F77_FOR_TARGET via passing f77 to GDB's compile procedure were removed in this commit commit 0ecee54cfd04a60e7ca61ae07c72b20e21390257 Author: Tom Tromey <tromey@redhat.com> Date: Wed Jun 29 17:50:47 2011 +0000 over 10 years ago. The last .f files in the testsuite by now are all being compiled by passing 'f90' to the GDB compile, thus only actually using F90_FOR_TARGET (array-element.f, block-data.f, subarray.f). Gfortran in this case is backwards compatible with most f77 code as claimed on gcc.gnu.org/fortran. The reason we'd like to get rid of this now is, that we'll be implementing a Fortran compiler identification mechanism, similar to the C/Cpp existing ones. It would be using the Fortran preprocessor macro defines to identify the Fortran compiler version at hand. We found it inconsequent to only implement this for f90 but, on the other hand, f77 seems deprecated. So, with this commit we remove the remaining lines for its support.
2022-05-03gdb/testsuite: fix mi-exec-run.exp with native-extended-gdbserver boardAndrew Burgess1-1/+1
When running with the native-extended-gdbserver board, I currently see one failure in gdb.mi/mi-exec-run.exp: FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout) In this test the MI interface should be started in a separate tty, which means we should have a CLI tty and an MI tty, however, this is not happening. Instead GDB is just started in MI mode and there is no CLI tty. The test script tries to switch between the CLI an MI terminals and look for some expected output on each, however, as there is no CLI terminal the expected output never arrives, and the test times out. It turns out that this is not a GDB problem, rather, this is an issue with argument passing within the test script. The proc default_mi_gdb_start expects to take a set of flags (strings) as arguments, each of flag is expected to be a separate argument. The default_mi_gdb_start proc collects all its arguments into a list using the special 'args' parameter name, and then iterates over this list to see which flags were passed. In mi_gdb_start, which forwards to default_mi_gdb_start, the arguments are also gathered into the 'args' parameter list, but are then expanded back to be separate arguments using the eval trick, i.e.: proc mi_gdb_start { args } { return [eval default_mi_gdb_start $args] } This ensures that when we arrive in default_mi_gdb_start each flag is a separate argument, rather than appearing as a single list containing all arguments. When using the native-extended-gdbserver board however, the file boards/native-extended-gdbserver.exp is loaded, and this file replaces the default mi_gdb_start with its own version. This new mi_gdb_start also gathers the arguments into an 'args' list, but forgets to expand the arguments out using the eval trick. As a result, when using the native-extended-gdbserver board, by the time we get to default_mi_gdb_start, we end up with the args list containing a single item, which is a list containing all the arguments the user passed. What this means is that if the user passes two arguments, then, in default_mi_gdb_start, instead of seeing two separate arguments, we see a single argument made by concatenating the two arguments together. The only place this is a problem is in the test mi-exec-run.exp, which (as far as I can see) is the only test where we might try to pass both arguments at the same time. Currently we think we passed both arguments to mi_gdb_start, but mi_gdb_start behaves as if no arguments were passed. This commit fixes the problem by making use of the eval trick within the native-extended-gdbserver version of mi_gdb_start. After this, the FAIL listed at the top of this message is resolved.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker27-27/+27
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script.
2021-12-10gdb/testsuite: respect GDBSERVER variable in remote-stdio-gdbserver "board"Jan Vrany1-1/+9
The comment on top of gdb/testsuite/boards/remote-stdio-gdbserver.exp says that user can specify path to gdbserver on remote system by setting GDBSERVER variable. However, this variable was ignored and /usr/bin/gdbserver was used unconditionally. This commit updates the code to respect GDBSERVER if set and fall back to /usr/bin/gdbserver if not.
2021-11-22[gdb/testsuite] Add target board dwarf64.expTom de Vries1-0/+23
Add a new target board dwarf64.exp, that runs test with -gdwarf64. Tested on x86_64-linux.
2021-10-13[gdb/testsuite] Fix gdb.base/batch-exit-status.exp with native-gdbserverTom de Vries1-1/+1
When running test-case gdb.base/batch-exit-status.exp with target board native-gdbserver, I run into (added missing double quotes for clarity): ... builtin_spawn $build/gdb/testsuite/../../gdb/gdb -nw -nx \ -data-directory $build/gdb/testsuite/../data-directory \ -iex "set height 0" -iex "set width 0" \ -ex "set auto-connect-native-target off" \ -iex "set sysroot" -batch ""^M : No such file or directory.^M PASS: gdb.base/batch-exit-status.exp: 1x: \ No such file or directory: [lindex $result 2] == 0 FAIL: gdb.base/batch-exit-status.exp: 1x: \ No such file or directory: [lindex $result 3] == $expect_status ... As in commit a02a90c114c "[gdb/testsuite] Set sysroot earlier in local-board.exp", the problem is the use of -ex for "set auto-connect-native-target off", which makes that the last command to be executed, and consequently determines the return status. Fix this by using -iex instead. Tested on x86_64-linux.
2021-09-12[gdb/testsuite] Set sysroot earlier in local-board.expTom de Vries1-1/+1
When running test-case gdb.base/batch-exit-status.exp for native, it passes. But with target board cc-with-debug-names, we run into (added missing double quotes for clarity): ... builtin_spawn $build/gdb/testsuite/../../gdb/gdb -nw -nx \ -data-directory $build/gdb/testsuite/../data-directory \ -iex "set height 0" -iex "set width 0" -ex "set sysroot" -batch ""^M : No such file or directory.^M PASS: gdb.base/batch-exit-status.exp: \ : No such file or directory\.: [lindex $result 2] == 0 FAIL: gdb.base/batch-exit-status.exp: \ : No such file or directory\.: [lindex $result 3] == $expect_status ... The difference between the passing and failing case is that with native we have (leaving out set height/width for brevity): ... $ gdb -batch ""; echo $? : No such file or directory. 1 ... and with target board cc-with-debug-names: ... $ gdb -ex "set sysroot" -batch ""; echo $? : No such file or directory. 0 ... The difference is expected. GDB returns the exit status of the last executed command. In the former case that's 'file ""', which fails. In the latter case, that's 'set sysroot', which succeeds. Fix this by setting sysroot using -iex instead of -ex in local-board.exp, such that we have the expected: ... $ gdb -iex "set sysroot" -batch ""; echo $? : No such file or directory. 1 ... Tested on x86_64-linux.
2021-05-21[gdb/testsuite] Add target board cc-with-gnu-debuglink.expTom de Vries1-0/+26
Add target board cc-with-gnu-debuglink.exp that splits off debuginfo into a seperate .debug file and links to it using .gnu_debuglink. Tested on x86_64-linux. gdb/ChangeLog: 2021-05-21 Tom de Vries <tdevries@suse.de> PR testsuite/25047 * contrib/cc-with-tweaks.sh: Handle -l. gdb/testsuite/ChangeLog: 2021-05-21 Tom de Vries <tdevries@suse.de> PR testsuite/25047 * boards/cc-with-gnu-debuglink.exp: New file.
2021-04-16gdb/testsuite: use -gdwarf-4 in simavr boardSimon Marchi1-0/+4
By default, when using the -g switch, avr-gcc generates stabs debug information. I think it would make more sense to test GDB against DWARF information, because stabs is obsolete by now, and nobody work on it. So change the simavr board to pass -gdwarf-4 as the debug flag. The downside is that users are probably more likely to use just -g, so we don't test GDB the same way as users are likely to use it. But in this case, if somebody comes and asks for help with GDB for AVR, I suggest we encourage them to use -gdwarf-4. I can't give stats about how that changes test results, because the testsuite is too broken. There is an internal error that happens quite frequently that needs to be investigated: /home/simark/src/wt/avr/gdb/trad-frame.h:143: internal-error: LONGEST trad_frame_saved_reg::addr() const: Assertion `m_kind == trad_frame_saved_reg_kind::ADDR' failed. I sent a question on the gcc mailing list, asking why stabs is the default: https://gcc.gnu.org/pipermail/gcc/2021-April/235309.html gdb/testsuite/ChangeLog: * boards/simavr.exp: Set debug_flags. Change-Id: I70e471fad3a79ab1d79d13dda8436bb9eb666e0a
2021-01-01Update copyright year range in all GDB filesJoel Brobecker25-25/+25
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2020-06-29gdb/testsuite: better handle failures in simavr board, reap simavr processSimon Marchi1-4/+33
This patch makes a few adjustments to the simavr.exp to handle tests that error out more gracefully. I put all the changes in the same patch because right now it's in a very bad shape, so it's very painful to do small incremental adjustements. I found that with these changes, it becomes reasonably stable. For example, the gdb.base/step-over-syscall.exp test is a bit buggy (stuff for another patch...), in that it calls gdb_load (through clean_restart) with a file that doesn't exist. The gdb_load implementation in simavr.exp gets called with a file that doesn't exist, and simavr (expectedly) fails to start. When this happens, we currently leave the $simavr_spawn_id variable set. However, because the simavr process has terminated, its spawn id is closed. When the next test tries to close the previous connection to simavr, it fails to, and this error is thrown: ERROR: close: spawn id exp86 not open while executing "close -i $simavr_spawn_id" (procedure "gdb_load" line 18) invoked from within In other words, any test ran after step-over-syscall.exp will have simavr.exp's gdb_load fail on it. This patch tries to make sure that simavr.exp's gdb_load only leaves simavr_spawn_id set if everything went fine. If we couldn't start simavr, don't see the expected output, or fail to connect to it, we close the spawn id (if needed) and unset simavr_spawn_id. As an additional precaution, I added a catch around the "close the previous connection" code. Ideally, this shouldn't be necessary, but I bet there are other similar scenarios where we might try to close an already close spawn id. So I think displaying a warning is better than messing up all following tests. Also, the board never wait'ed for the simavr process, resulting in tons of zombie simavr processes hanging around. This patch adds some calls to "wait" whenever we close the connection (or realize it is already closed), which seems to fix the problem. Finally I switched a `gdb_expect` to bare `expect`, where we wait for the "listening" message from simavr. I found it necessary because gdb_expect (through remote_expect) adds a `-i <gdb spawn id> -timeout 10`. So if for some reason the GDB process has crashed in the mean time, this expect will unexpectedly error out with a `spawn id <gdb spawn id> not open`. Therefore, change `gdb_expect` to `expect` so that we only deal with simavr's spawn id here. Here are the results on TESTS="gdb.base/*.exp" before: # of expected passes 4816 # of unexpected failures 4433 # of known failures 2 # of unresolved testcases 300 # of untested testcases 143 # of unsupported tests 7 # of paths in test names 2 # of duplicate test names 10 and after: # of expected passes 21957 # of unexpected failures 1564 # of expected failures 8 # of unknown successes 1 # of known failures 31 # of unresolved testcases 532 # of untested testcases 153 # of unsupported tests 28 # of paths in test names 2 # of duplicate test names 32 I tested using simavr's current master (7c254e2081b5). gdb/testsuite/ChangeLog: * boards/simavr.exp (gdb_load): Catch errors when closing previous connection. Close connection, wait for process and unset simavr_spawn_id on failure. Change-Id: I695fc765e1c22e1d1dc0b08e0f5141244986b868
2020-05-25[gdb/testsuite] Add target board gold-gdb-indexTom de Vries1-0/+45
Add new target board that uses gold to add a .gdb_index section, enabled by -ggnu-pubnames. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-25 Tom de Vries <tdevries@suse.de> * boards/gold-gdb-index.exp: New file.
2020-05-25gdb/testsuite: add simavr.exp boardSimon Marchi1-0/+95
This patch adds a board file for against a simavr target (so, for the AVR architecture). simavr, when started with option -g, runs a GDB stub on port 1234. In the current latest release (1.6), the port is hardcoded to 1234. But in master, there is the option to choose another port. So while the board file hardcodes the port today, in the future it should be possible to let the user choose a port, or automatically select a free port. It is easy enough to run, make sure you have avr-gcc/avr-g++ and simavr installed, and as usual just run: make check RUNTESTFLAGS="--target_board=simavr" The following environment variables influence the behavior of the board file: - SIMAVR_MCU: type of chip to simulate - SIMAVR_PATH: path to simavr binary (useful if you build your own simavr or for some reason it is not simply called `simavr`. As expected, there are a lot of failures. Many tests use some features not supported by such a target, and I suppose there are real GDB bugs too. But a lot also passes (including tests that actually run stuff), so this board file should still help to validate changes to the AVR architecture support. These are the results I got of running tests gdb.base/*.exp: # of expected passes 20926 # of unexpected failures 2257 # of expected failures 14 # of unknown successes 1 # of known failures 13 # of unresolved testcases 592 # of untested testcases 156 # of unsupported tests 30 # of paths in test names 3 # of duplicate test names 56 gdb/testsuite/ChangeLog: * boards/simavr.exp: New file. Change-Id: Ib7fa8c4e2e90b08b104bb9b552df37779de3bc21
2020-05-25gdb/testsuite: support passing inferior arguments with native-gdbserver boardSimon Marchi3-5/+2
This patch makes it possible to run tests requiring passing arguments to the inferior with the native-gdbserver board. The end goal is to write a test that verifies passing arguments to the inferior works, and to have that test exercise inferior arguments passed on the gdbserver command line, when using the native-gdbserver target board (in addition to the other boards). This is done in the next patch. With the native-gdbserver target board, gdbserver is started in gdb_reload (implemented in config/gdbserver.exp), called in gdb_run_cmd. gdb_run_cmd already supposedly accepts inferior arguments (although that feature does not seem to be used anywhere), which it passes to the `run` command, for non-stub target boards. I've changed gdb_run_cmd so that it forwards these arguments to gdb_reload as well. gdb_reload passes them to gdbserver_run, and they eventually make their way to the gdbserver command line. gdb_run_cmd currently accepts `args` (the varargs of tcl), which means it receives inferior arguments as a list. This won't work with arguments with spaces, because they will end up being formatted with curly braces like this: % set args [list hello "with spaces" world] hello {with spaces} world % puts "run $args" run hello {with spaces} world I've changed it to accept a single string that is passed to `run` and gdb_reload. I've done the same change in gdb_start_cmd and gdb_starti_cmd, although these two are not used with native-gdbserver. I've changed all gdb_reload implementations in the tree to accept a new inferior_args argument, although most of them don't do anything with it (and don't need to). People maintaining target boards out of tree will need to do the same. I found two tests to adjust to avoid adding new failures or errors. These tests needed new [use_gdb_stub] checks, because they rely on having GDB run new processes. These are guarded by a [target_info exists noargs], which made them get skipped on native-gdbserver. But now that the native-gdbserver board supports args, this is no longer enough. Note that with this change, noargs and use_gdb_stub are orthogonal. It took me a moment to grasp this, so I thought I would spell out the different possible situations: - !noargs and !use_gdb_stub: inferior process started by gdb, can pass args - noargs and !use_gdb_stub: inferior process started by gdb (perhaps through extended-remote protocol, the simulator, some other target), but that target doesn't support inferior arguments - noargs and use_gdb_stub: inferior process started by some other program to which GDB connects using the remote protocol, that program does not support passing args to the inferior process - !noargs and use_gdb_stub: inferior process started by some other program to which GDB connects u sing the remote protocol, that program supports passing args to the inferior process gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_run_cmd): Change argument from args to inferior_args. Pass it to gdb_reload. (gdb_start_cmd, gdb_starti_cmd): Change argument from args to inferior_args. (gdb_reload): Add inferior_args argument. * config/gdbserver.exp (gdb_reload): Add inferior_args argument, pass it to gdbserver_run. * boards/native-gdbserver.exp: Do not set noargs. * boards/native-extended-gdbserver.exp (gdb_reload): Add inferior_args argument. * boards/stdio-gdbserver-base.exp (gdb_reload): Likewise. * gdb.base/a2-run.exp: Check for use_gdb_stub. * gdb.base/args.exp: Likewise. Change-Id: Ibda027c71867157852f34700342ab31edf39e4d8
2020-05-25[gdb/testsuite] Add target board goldTom de Vries1-0/+32
Add a target board that uses the gold linker. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-25 Tom de Vries <tdevries@suse.de> * boards/gold.exp: New file.
2020-04-25[gdb/testsuite] Add target board debug-typesTom de Vries1-0/+41
This patch adds a target board debug-types that switches on -fdebug-types-section by default. This -fdebug-types-section option is a gcc option that enables the generation of a .debug_types section, which is only effective for DWARF version 4. There are two other boards that enable this: dwarf4-gdb-index and fisson, but while those test some meaningful combination of options, this board is intended to test only -fdebug-types-section. Current results with gcc 7.5.0 are: ... === gdb Summary === # of expected passes 75832 # of unexpected failures 2841 # of expected failures 130 # of known failures 75 # of unresolved testcases 22 # of untested testcases 37 # of unsupported tests 83 ... Related known issues: - PR gcc/90232 - "gcc drops top-level dies with -fdebug-types-section" - PR gdb/25875 - "segv in ada_discrete_type_low_bound" - PR gdb/14148 - "-fdebug-types-section regresses static scope of types" Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-04-25 Tom de Vries <tdevries@suse.de> * boards/debug-types.exp: New file.
2020-03-06[gdb/testsuite] Fix "text file busy" errors with cc-with-tweaks.expTom de Vries1-4/+2
When using target board cc-with-gdb-index.exp and running tests in parallel, we run into: ... gdb compile failed, gdb/contrib/gdb-add-index.sh: line 86: \ build/gdb/testsuite/gdb.sh: Text file busy ... The problem is that because of the parallel test run, gdb.sh is created for every single test-case, and eventually gdb.sh is overwritten while being executed. Fix this by creating gdb.sh only once. Tested on x86_64-linux with target board cc-with-gdb-index.exp, using both a serial and parallel -j 5 test run. gdb/testsuite/ChangeLog: 2020-03-06 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (tentative_rename, cached_file): New proc. * boards/cc-with-tweaks.exp: Use cached_file to create gdb.sh.
2020-02-14Have testsuite find gdbserver in new locationTom Tromey1-1/+1
This updates the gdb testsuite to look for gdbserver in its new location. The old location is also checked for, on the theory that perhaps someone sets GDB to a full path for install testing. gdb/testsuite/ChangeLog 2020-02-14 Tom Tromey <tom@tromey.com> * lib/gdbserver-support.exp (find_gdbserver): Find gdbserver in build directory. * boards/gdbserver-base.exp: Update path to gdbserver. Change-Id: If03db762ba53882ddfaf2d2d516de14c3fa03938
2020-01-01Update copyright year range in all GDB files.Joel Brobecker21-21/+21
gdb/ChangeLog: Update copyright year range in all GDB files.
2019-10-16gdb/testsuite: Allow cc-with-tweaks board file to be used with FortranAndrew Burgess1-0/+10
The board file cc-with-tweaks is used as the core for lots of other board files, for example cc-with-gdb-index and cc-with-debug-names. This commit extends cc-with-tweaks so that it will wrap the Fortran compiler, allowing for more test coverage. I tested all of the board files that make use of cc-with-tweaks running the gdb.fortran/*.exp test set, and in some cases I did see extra failures. The "standard" results are: === gdb Summary === # of expected passes 953 # of known failures 2 With board file 'cc-with-dwz-m': === gdb Summary === # of expected passes 903 # of unexpected failures 1 # of known failures 2 # of untested testcases 4 With board file 'dwarf4-gdb-index': === gdb Summary === # of expected passes 950 # of unexpected failures 3 # of known failures 2 With board file 'fission-dwp': === gdb Summary === # of expected passes 949 # of unexpected failures 4 # of known failures 2 Despite these extra failure I don't think this should prevent this change going in as these failures presumably already exist in GDB. gdb/testsuite/ChangeLog: * boards/cc-with-tweaks.exp: Setup F90_FOR_TARGET and F77_FOR_TARGET. Change-Id: I06d412f94d0e119ad652dd6c20829f6705a54622
2019-09-10Add Ada support to cc-with-tweaks.expTom Tromey1-0/+5
This adds Ada support to the cc-with-tweaks.exp board file, so that we can test Ada this way. The cc-with-tweaks.sh script already works reasonably well as a wrapper for gnatmake. gdb/testsuite/ChangeLog 2019-09-10 Tom Tromey <tromey@adacore.com> * boards/cc-with-tweaks.exp: Set GNATMAKE_FOR_TARGET.
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.
generated by cgit v1.1 at 2025-04-03 18:16:30 +0000