aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/lib/gdb.exp
AgeCommit message (Collapse)AuthorFilesLines
2023-12-13gdb: improve error reporting for 'save gdb-index'Andrew Burgess1-43/+70
While making recent changes to 'save gdb-index' command I triggered some errors -- of the kind a user might be expected to trigger if they do something wrong -- and I didn't find GDB's output as helpful as it might be. For example: $ gdb -q /tmp/hello.x ... (gdb) save gdb-index /non_existing_dir Error while writing index for `/tmp/hello': mkstemp: No such file or directory. That the error message mentions '/tmp/hello', which does exist, but doesn't mention '/non_existing_dir', which doesn't is, I think, confusing. Also, I find the 'mkstemp' in the error message confusing for a user facing error. A user might not know what mkstemp means, and even if they do, that it appears in the error message is an internal GDB detail. The user doesn't care what function failed, but wants to know what was wrong with their input, and what they should do to fix things. Similarly, for a directory that does exist, but can't be written to: (gdb) save gdb-index /no_access_dir Error while writing index for `/tmp/hello': mkstemp: Permission denied. In this case, the 'Permission denied' might make the user thing there is a permissions issue with '/tmp/hello', which is not the case. After this patch, the new errors are: (gdb) save gdb-index /non_existing_dir Error while writing index for `/tmp/hello': `/non_existing_dir': No such file or directory. and: (gdb) save gdb-index /no_access_dir Error while writing index for `/tmp/hello': `/no_access_dir': Permission denied. we also have: (gdb) save gdb-index /tmp/not_a_directory Error while writing index for `/tmp/hello': `/tmp/not_a_directory': Is not a directory. I think these do a better job of guiding the user towards fixing the problem. I've added a new test that exercises all of these cases, and also checks the case where a user tries to use an executable that already contains an index in order to generate an index. As part of the new test I've factored out some code from ensure_gdb_index (lib/gdb.exp) into a new proc (get_index_type), which I've then used in the new test. I've confirmed that all the tests that use ensure_gdb_index still pass. During review it was pointed out that the testsuite proc have_index (lib/gdb.exp) is similar to the new get_index_type proc, so I've rewritten have_index to also use get_index_type, I've confirmed that all the tests that use have_index still pass. Nothing that worked correctly before this patch should give an error after this patch; I've only changed the output when the user was going to get an error anyway. Reviewed-By: Tom de Vries <tdevries@suse.de> Reviewed-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
2023-12-05gdb/testsuite: Update worker thread show assertionRichard Bunt1-1/+1
Commit 33ae45434d0 updated the text reported by GDB when showing the number of worker threads. However, it neglected to update the assertions using this text, which caused index-file.exp to fail. This commit corrects this omission. Tested index-file.exp is fixed on my local machine. Approved-By: Tom Tromey <tom@tromey.com>
2023-11-28gdb/testsuite: improve test regexp in gdb_get_worker_threadsAndrew Burgess1-1/+1
I spotted I made a small mistake in this commit: commit aff250145af6c7a8ea9332bc1306c1219f4a63db Date: Fri Nov 24 12:04:36 2023 +0000 gdb: generate gdb-index identically regardless of work thread count In this commit I added a new proc in testsuite/lib/gdb.exp called gdb_get_worker_threads. This proc uses gdb_test_multiple with two possible patterns. One pattern is anchored with '^', while the other is missing the '^' which it could use. This commit adds the missing '^'.
2023-11-28gdb: generate gdb-index identically regardless of work thread countAndrew Burgess1-0/+15
It was observed that changing the number of worker threads that GDB uses (maintenance set worker-threads NUM) would have an impact on the layout of the generated gdb-index. The cause seems to be how the CU are distributed between threads, and then symbols that appear in multiple CU can be encountered earlier or later depending on whether a particular CU moves between threads. I certainly found this behaviour was reproducible when generating an index for GDB itself, like: gdb -q -nx -nh -batch \ -eiex 'maint set worker-threads NUM' \ -ex 'save gdb-index /tmp/' And then setting different values for NUM will change the generated index. Now, the question is: does this matter? I would like to suggest that yes, this does matter. At Red Hat we generate a gdb-index as part of the build process, and we would ideally like to have reproducible builds: for the same source, compiled with the same tool-chain, we should get the exact same output binary. And we do .... except for the index. Now we could simply force GDB to only use a single worker thread when we build the index, but, I don't think the idea of reproducible builds is that strange, so I think we should ensure that our generated indexes are always reproducible. To achieve this, I propose that we add an extra step when building the gdb-index file. After constructing the initial symbol hash table contents, we will pull all the symbols out of the hash, sort them, then re-insert them in sorted order. This will ensure that the structure of the generated hash will remain consistent (given the same set of symbols). I've extended the existing index-file test to check that the generated index doesn't change if we adjust the number of worker threads used. Given that this test is already rather slow, I've only made one change to the worker-thread count. Maybe this test should be changed to use a smaller binary, which is quicker to load, and for which we could then try many different worker thread counts. Approved-By: Tom Tromey <tom@tromey.com>
2023-10-12Fix test suite failure in file-then-restart.expTom Tromey1-10/+15
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-10-06process-dies-while-detaching.exp: Exit early if GDB misses sync breakpointThiago Jung Bauermann1-2/+2
I'm seeing a lot of variability in the failures of gdb.threads/process-dies-while-detaching.exp on aarch64-linux. On this platform, a problem yet to be investigated causes GDB to miss the _exit breakpoint. What happens next is random because after missing that breakpoint, GDB is out of sync with the inferior. This causes the tests following that point in the testcase to fail in a random way. In this scenario it's better to exit the testcase early to avoid random results in the testsuite. We are relying on gdb_continue_to_breakpoint to return the result of gdb_test_multiple. This is already the case because in Tcl the return value of a function is the return value of the last command it runs. But change gdb_continue_to_breakpoint to explicitly return this value, to make it clear this is the intended behaviour. Tested on aarch64-linux. Tested-By: Guinevere Larsen <blarsen@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-04gdb/testsuite: XFAIL some gdb.base/fileio.expGuinevere Larsen1-0/+20
Some gdb.base/fileio.exp tests expect the inferior to not have write access to some files. If the test is being run as root, this is never possible. This commit adds a way to identify if the user is root and xfails the tests that expect no write access. Approved-By: Tom de Vries <tdevries@suse.de>
2023-10-04sme: Add SVE/SME testcasesLuis Machado1-0/+249
Add 5 SVE/SME tests to exercise all the new features like reading/writing registers, pseudo-registers, signal frames and core files. - Sanity check for SME: Gives a brief smoke test to make sure the most basic of features are working correctly. - ZA unavailability tests: Validates the behavior/content of the ZA register is correct when no payload is available. It also exercises changing the vector lengths. - ZA availability tests: These tests exercise reading/writing to all the possible ZA pseudo-registers, and validates the state is correct. - Core file tests: Validates that core file reading and writing works correctly and that all state dumped/loaded is sane. This is exercised for both Linux Kernel core files and gcore core files. - Signal frame tests: Validates the correct restoration of SME/SVE/FPSIMD values across signal frames. Since some of these tests are very lengthy and take a little while to run (under QEMU at the moment), I decided to parallelize them into smaller chunks so we can throw some more CPU power at them so they run faster. I'd still like to add a few more tests to give the testsuite more coverage in the areas of SME/SVE. Hopefully in the near future that will happen. Just a reminder that these SME tests are currently unsupported when gdb is connected to a remote target. That's because the RSP doesn't support communicating changes in vector lenghts mid-execution, so gdb will always get wrong state from the remote target. Co-Authored-By: Ezra Sitorus <ezra.sitorus@arm.com> Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2023-09-29Support the NO_COLOR environment variableTom Tromey1-1/+20
I ran across this site: https://no-color.org/ ... which lobbies for tools to recognize the NO_COLOR environment variable and disable any terminal styling when it is seen. This patch implements this for gdb. Regression tested on x86-64 Fedora 38. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Reviewed-by: Kevin Buettner <kevinb@redhat.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-08-29[gdb/testsuite] Fix false negative in have_host_localeTom de Vries1-0/+2
In test-case gdb.tui/pr30056.exp we check for: ... require {have_host_locale C.UTF-8} ... The "C.UTF-8" is normalized by have_host_locale to "c.utf8", before trying to find it in the list returned by host_locales. On my development platform, "locale -a" lists C.utf8, which is normalized to "c.utf8" by host_locales, so there's a match and have_host_locale returns true. On another platform however, "locale -a" lists C.UTF-8, which is normalized to "c.utf-8" by host_locales, so there's no match and have_host_locale returns false. Fix this by also dropping the dash in host_locales. Tested on x86_64-linux.
2023-08-29[gdb/testsuite] Check for sys/random.h in gdb.reverse/getrandom.expTom de Vries1-0/+8
When running test-case gdb.reverse/getrandom.exp on a system with eglibc 2.19, we run into: ... gdb compile failed, gdb.reverse/getrandom.c:18:24: fatal error: \ sys/random.h: No such file or directory #include <sys/random.h> ^ compilation terminated. === gdb Summary === # of untested testcases 1 ... and: ... UNTESTED: gdb.reverse/getrandom.exp: failed to prepare ... Fix this by testing for the presence of the header, such that we have instead: ... UNSUPPORTED: gdb.reverse/getrandom.exp: require failed: \ have_system_header sys/random.h ... Tested on x86_64-linux and i686-linux.
2023-08-24gdb/testsuite: fix gdb.reverse/solib-*.exp tests when using clangGuinevere Larsen1-3/+3
The tests gdb.reverse/solib-precsave.exp and solib-reverse.exp have the assumption that line tables will have an entry for the closing } in a function. Not all compiles do this, one example being clang. To fix this, this commit changes the function in shr2.c to have multiple lines, and the test to accept either line as a correct step location. To properly re-sync the inferiors, the function repeat_cmd_until had to be slightly changed to work with empty "current locations", so that we are able to step through multiple lines. This also changes the annotations used to determine the breakpoint locations in solib-reverse.c, adding a simple variable assignment right before the return statement. This way GDB will not set a breakpoint in the closing } line. Approved-By: Tom Tromey <tom@tromey.com>
2023-08-02[gdb/dap] Disable DAP for python <= 3.5Tom de Vries1-0/+25
DAP requires python module typing, which is supported starting python 3.5. Make this formal by: - disabling the dap interpreter for python version < 3.5 - returning 0 in allow_dap_tests for python version < 3.5 Approved-By: Tom Tromey <tom@tromey.com> PR dap/30708 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30708
2023-07-31[gdb/testsuite] Set TSAN_OPTIONS by default to history_size=7Tom de Vries1-0/+8
I build gdb with -fsanitize=thread and ran the testsuite, and ran into the case that a race is detected, but we see the full stack trace only for one of the two accesses, and the other one is showing "failed to restore the stack". Try to prevent this by setting ThreadSanitizer flag history_size [1] to the maximum (7) by default, as suggested here [2]. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> [1] https://github.com/google/sanitizers/wiki/ThreadSanitizerFlags [2] https://groups.google.com/g/thread-sanitizer/c/VzSWE7UxhIE
2023-07-31Set PYTHONMALLOC in the test suiteTom Tromey1-0/+4
Setting PYTHONMALLOC helped me locate an earlier bug. It seems to me that there aren't big downsides to always setting this during testing, and it might help find other bugs in the future.
2023-07-14Add a have_native_target helper function for use with require.John Baldwin1-0/+14
Move logic from auto-connect-native-target.exp into this helper.
2023-07-07gdb: check max-value-size when reading strings for printfAndrew Burgess1-0/+30
I noticed that the printf code for strings, printf_c_string and printf_wide_c_string, don't take max-value-size into account, but do load a complete string from the inferior into a GDB buffer. As such it would be possible for an badly behaved inferior to cause GDB to try and allocate an excessively large buffer, potentially crashing GDB, or at least causing GDB to swap lots, which isn't great. We already have a setting to protect against this sort of thing, the 'max-value-size'. So this commit updates the two function mentioned above to check the max-value-size and give an error if the max-value-size is exceeded. If the max-value-size is exceeded, I chose to continue reading inferior memory to figure out how long the string actually is, we just don't store the results. The benefit of this is that when we give the user an error we can tell the user how big the string actually is, which would allow them to correctly adjust max-value-size, if that's what they choose to do. The default for max-value-size is 64k so there should be no user visible changes after this commit, unless the user was previously printing very large strings. If that is the case then the user will now need to increase max-value-size.
2023-06-22[gdb/testsuite] Clean or check standard_output_file dir in gdb_initTom de Vries1-0/+41
In commit e2adba909e7 ("[gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp") I added some code in the test-case to remove some files at the start of the test-case: ... remote_file host delete [standard_output_file prog.o] remote_file host delete [standard_output_file prog.ali] ... Then in commit b7b77500dc5 ("[gdb/testsuite] Clean standard_output_file dir in gdb_init") I tried to do this more structurally, by cleaning up the entire standard_output_file directory, for all test-cases. This caused a regression when using "make check -j 2", due to the cleanup removing the active gdb.log, so I reverted the commit. Try again, this time handling the two cases separately. If the standard_output_file directory contains an active gdb.log, check that the directory contains no files other than gdb.log and gdb.sum. This puts the reponsibility for the cleanup at the callers in gdb/testsuite/Makefile.in which use --outdir. If the standard_output_file directory doesn't contain an active gdb.log, clean it by removing the entire directory. An exception is made for performance tests, where cleaning up the standard_output_file dir is the wrong thing to do, because an invocation with GDB_PERFTEST_MODE == run is intended to reuse binaries left there by an earlier invocation with GDB_PERFTEST_MODE == compile. Tested on x86_64-linux. Suggested-By: Tom Tromey <tom@tromey.com> Reviewed-By: Tom Tromey <tom@tromey.com> Tested-By: Luis Machado <luis.machado@arm.com>
2023-06-21[gdb/testsuite] Add have_host_localeTom de Vries1-0/+36
With test-case gdb.tui/pr30056.exp, I run into: ... sh: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8)^M ... and then subsequently into: ... WARNING: timeout in accept_gdb_output FAIL: gdb.tui/pr30056.exp: Control-C ... This is on a CentOS 7 distro for powerpc64le. Either it has no C.UTF-8 support, or it's not installed: ... $ locale -a | grep ^C C $ ... Fix this by: - adding a new proc have_host_locale, and - using it in all test-cases using setenv LC_ALL. Tested on powerpc64le-linux and x86_64-linux.
2023-06-19Revert "[gdb/testsuite] Clean standard_output_file dir in gdb_init"Tom de Vries1-3/+0
This reverts commit b7b77500dc56e5bc21473dd4f3dde2543d894557.
2023-06-18[gdb/testsuite] Clean standard_output_file dir in gdb_initTom de Vries1-0/+3
In commit e2adba909e7 ("[gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp") I added some code in the test-case to remove some files at the start of the test-case: ... remote_file host delete [standard_output_file prog.o] remote_file host delete [standard_output_file prog.ali] ... Replace this with cleaning up the entire directory instead, for all test-cases. Tested on x86_64-linux. Suggested-By: Tom Tromey <tom@tromey.com> Reviewed-By: Tom Tromey <tom@tromey.com>
2023-06-13[gdb/testsuite] Allow procs with default value args in with_overrideTom de Vries1-2/+18
Currently proc with_override does not work with procs with default value args. Fix this, and add a test-case excercising this scenario. Tested on x86_64-linux.
2023-06-12gdb/testsuite: Testing with the armflang compilerRichard Bunt1-1/+4
Currently the Fortran test suite does not run with armflang because the compiler detection fails. This in turn means fortran_runto_main does not know which main method to use to start a test case. Fortran compiler detection was added in 44d469c5f85; however, the commit message notes that it was not tested with armflang. This commit tests and fixes up a minor issue to get the detection working. The goal here is to get the tests running and preventing further regressions during future work. This change does not do anything to fix existing failures. >From what I can understand, the auto detection leverages the preprocessor to extract the Fortran compiler identity from the defines. This preprocessor output is then evaluated by the test suite to import these defines. In the case of armflang, this evaluation step is disrupted by the presence of the following warning: $ armflang -E -fdiagnostics-color=never testsuite/lib/compiler.F90 -o compiler.exp $ clang-13: warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument] The evaluation logic is already set up to filter this warning, but the prefix differs. This commit fixes the issue by updating the filter to exclude the armflang flavour of warning. gdb.fortran regression tests run with GNU, Intel and Intel LLVM. No regressions detected. The gdb.fortran test results with ACfL 23.04.1 are as follows. Before: # of expected passes 560 # of unexpected failures 113 # of unresolved testcases 2 # of untested testcases 5 # of duplicate test names 2 After: # of expected passes 5388 # of unexpected failures 628 # of known failures 10 # of untested testcases 8 # of unsupported tests 5 # of duplicate test names 5 As can be seen from the above, there are now considerably more passing assertions. Reviewed-By: Luis Machado <luis.machado@arm.com> Approved-By: Tom Tromey <tom@tromey.com>
2023-06-09[gdb] Fix typosTom de Vries1-1/+1
Fix typos: - reponse -> response - inital -> initial - a -> an
2023-06-05[gdb] Fix more typosTom de Vries1-1/+1
Fix some more typos: - distinquish -> distinguish - actualy -> actually - singe -> single - frash -> frame - chid -> child - dissassembler -> disassembler - uninitalized -> uninitialized - precontidion -> precondition - regsiters -> registers - marge -> merge - sate -> state - garanteed -> guaranteed - explictly -> explicitly - prefices (nonstandard plural) -> prefixes - bondary -> boundary - formated -> formatted - ithe -> the - arrav -> array - coresponding -> corresponding - owend -> owned - fials -> fails - diasm -> disasm - ture -> true - tpye -> type There's one code change, the name of macro SIG_CODE_BONDARY_FAULT changed to SIG_CODE_BOUNDARY_FAULT. Tested on x86_64-linux.
2023-06-03[gdb] Fix typosTom de Vries1-1/+1
Fix a few typos: - implemention -> implementation - convertion(s) -> conversion(s) - backlashes -> backslashes - signoring -> ignoring - (un)ambigious -> (un)ambiguous - occured -> occurred - hidding -> hiding - temporarilly -> temporarily - immediatelly -> immediately - sillyness -> silliness - similiar -> similar - porkuser -> pokeuser - thats -> that - alway -> always - supercede -> supersede - accomodate -> accommodate - aquire -> acquire - priveleged -> privileged - priviliged -> privileged - priviledges -> privileges - privilige -> privilege - recieve -> receive - (p)refered -> (p)referred - succesfully -> successfully - successfuly -> successfully - responsability -> responsibility - wether -> whether - wich -> which - disasbleable -> disableable - descriminant -> discriminant - construcstor -> constructor - underlaying -> underlying - underyling -> underlying - structureal -> structural - appearences -> appearances - terciarily -> tertiarily - resgisters -> registers - reacheable -> reachable - likelyhood -> likelihood - intepreter -> interpreter - disassemly -> disassembly - covnersion -> conversion - conviently -> conveniently - atttribute -> attribute - struction -> struct - resonable -> reasonable - popupated -> populated - namespaxe -> namespace - intialize -> initialize - identifer(s) -> identifier(s) - expection -> exception - exectuted -> executed - dungerous -> dangerous - dissapear -> disappear - completly -> completely - (inter)changable -> (inter)changeable - beakpoint -> breakpoint - automativ -> automatic - alocating -> allocating - agressive -> aggressive - writting -> writing - reguires -> requires - registed -> registered - recuding -> reducing - opeartor -> operator - ommitted -> omitted - modifing -> modifying - intances -> instances - imbedded -> embedded - gdbaarch -> gdbarch - exection -> execution - direcive -> directive - demanged -> demangled - decidely -> decidedly - argments -> arguments - agrument -> argument - amespace -> namespace - targtet -> target - supress(ed) -> suppress(ed) - startum -> stratum - squence -> sequence - prompty -> prompt - overlow -> overflow - memember -> member - languge -> language - geneate -> generate - funcion -> function - exising -> existing - dinking -> syncing - destroh -> destroy - clenaed -> cleaned - changep -> changedp (name of variable) - arround -> around - aproach -> approach - whould -> would - symobl -> symbol - recuse -> recurse - outter -> outer - freeds -> frees - contex -> context Tested on x86_64-linux. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-05-30[gdb] Mention --with/without-system-readline for --configurationTom de Vries1-0/+8
Simon reported that the new test-case gdb.tui/pr30056.exp fails with system readline. This is because the test-case requires a fix in readline that's present in our in-repo copy of readline, but most likely not in any system readline yet. Fix this by: - mentioning --with-system-readline or --without-system-readline in the configuration string. - adding a new proc with_system_readline that makes this information available in the testsuite. - using this in test-case gdb.tui/pr30056.exp to declare it unsupported for --with-system-readline. Tested on x86_64-linux. Reported-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-05-16gdb/testsuite: make gdb_supported_languages a caching procAndrew Burgess1-5/+23
Rewrite gdb_supported_languages as a caching proc that actually queries GDB for the list of supported languages, rather than just containing a hard-coded list of languages. There's only one test that uses this proc right now, gdb.python/py-function.exp, and that still passes after this change, with no changes in the test names.
2023-05-12gdb/testsuite: extend special '^' handling to gdb_test_multipleAndrew Burgess1-12/+31
The commit: commit 08ec06d6440745ef9204d39197aa1e732df41056 Date: Wed Mar 29 10:41:07 2023 +0100 gdb/testsuite: special case '^' in gdb_test pattern Added some special handling of '^' to gdb_test -- a leading '^' will cause the command regexp to automatically be included in the expected output pattern. It was pointed out that the '-wrap' flag of gdb_test_multiple is supposed to work in the same way as gdb_test, and that the recent changes for '^' had not been replicated for gdb_test_multiple. This patch addresses this issue. So, after this commit, the following two constructs should have the same meaning: gdb_test "command" "^output" "test name" gdb_test_multiple "command" "test name" { -re -wrap "^output" { pass $gdb_test_name } } In both cases the '^' will case gdb.exp to inject a regexp that matches 'command' after the '^' and before the 'output', this is in addition to adding the $gdb_prompt pattern after 'output' in the normal way. The special '^' handling is only applied when '-wrap' is used, as this is the only mode that aims to mimic gdb_test. While working on this patch I realised that I could actually improve the logic for the special '^' handling in the case where the expected output pattern is empty. I replicated these updates for both gdb_test and gdb_test_multiple in order to keep these two paths in sync. There were a small number of tests that needed adjustment after this change, mostly just removing command regexps that are now added automatically, but the gdb.base/settings.exp case was a little weird as it turns out trying to match a single blank line is probably harder now than it used to be -- still, I suspect this is a pretty rare case, so I think the benefits (improved anchoring) outweigh this small downside (IMHO).
2023-05-12[gdb/testsuite] Make is_64_target more robustTom de Vries1-1/+8
I ran test-case gdb.dwarf2/opt-out-not-implptr.exp with make-check-all.sh, and with target board dwarf64 ran into: ... FAIL: gdb.dwarf2/opt-out-not-implptr.exp: print noptr ... due to is_target_64 failing because of: ... builtin_spawn -ignore SIGHUP gcc -fno-stack-protector \ -fdiagnostics-color=never -w -c -gdwarf64 -g -o is_64_target.o \ is_64_target.c^M gcc: error: '-gdwarf64' is ambiguous; use '-gdwarf-64' for DWARF version or \ '-gdwarf -g64' for debug level^M compiler exited with status 1 ... The FAIL is the same FAIL I run into with target board unix/-m32: is_target_64 fails for both cases. The reason that is_target_64 is failing for target board dwarf64, is because of using system compiler 7.5.0 which doesn't support -gdwarf64. Fix this by making is_target_64 use nodebug instead of debug for compilation. Tested on x86_64-linux.
2023-05-05gdb/testsuite: more newline pattern cleanupAndrew Burgess1-5/+5
After this commit: commit e2f620135d92f7cd670af4e524fffec7ac307666 Date: Thu Mar 30 13:26:25 2023 +0100 gdb/testsuite: change newline patterns used in gdb_test It was pointed out in PR gdb/30403 that the same patterns can be found in other lib/gdb.exp procs and that it would probably be a good idea if these procs remained in sync with gdb_test. Actually, the bug specifically calls out gdb_test_multiple when using with '-wrap', but I found a couple of other locations in gdb_continue_to_breakpoint, gdb_test_multiline, get_valueof, and get_local_valueof. In all these locations one or both of the following issues are addressed: 1. A leading pattern of '[\r\n]*' is pointless. If there is a newline it will be matched, but if there is not then the testsuite doesn't care. Also, as expect is happy to skip non-matched output at the start of a pattern, if there is a newline expect is happy to skip over it before matching the rest. As such, this leading pattern is removed. 2. Using '\[\r\n\]*$gdb_prompt' means that we will swallow unexpected blank lines at the end of a command's output, but also, if the pattern from the test script ends with a '\r', '\n', or '.' then these will partially match the trailing newline, with the remainder of the newline matched by the pattern from gdb.exp. This split matching doesn't add any value, it's just something that has appeared as a consequence of how gdb.exp was originally written. In this case the '\[\r\n\]*' is replaced with '\r\n'. I've rerun the testsuite and fixed the regressions that I saw, these were places where GDB emits a blank line at the end of the command output, which we now need to explicitly match in the test script, this was for: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp gdb.guile/guile.exp gdb.python/python.exp Or a location where the test script was matching part of the newline sequence, while gdb.exp was previously matching the remainder of the newline sequence. Now we rely on gdb.exp to match the complete newline sequence, this was for: gdb.base/commands.exp Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30403
2023-04-27gdb/testsuite: special case '^' in gdb_test patternAndrew Burgess1-4/+18
In this commit I propose that we add special handling for the '^' when used at the start of a gdb_test pattern. Consider this usage: gdb_test "some_command" "^command output pattern" I think the intention here is pretty clear - run 'some_command', and the output from the command should be exactly 'command output pattern'. After the previous commit which tightened up how gdb_test matches the final newline and prompt we know that the only thing after the output pattern will be a single newline and prompt, and the leading '^' ensures that there's no output before 'command output pattern', so this will do what I want, right? ... except it doesn't. The command itself will also needs to be matched, so I should really write: gdb_test "some_command" "^some_command\r\ncommand output pattern" which will do what I want, right? Well, that's fine until I change the command and include some regexp character, then I have to write: gdb_test "some_command" \ "^[string_to_regexp some_command]\r\ncommand output pattern" but this all gets a bit verbose, so in most cases I simply don't bother anchoring the output with a '^', and a quick scan of the testsuite would indicate that most other folk don't both either. What I propose is this: the *only* thing that can appear immediately after the '^' is the command converted into a regexp, so lets do that automatically, moving the work into gdb_test. Thus, when I write: gdb_test "some_command" "^command output pattern" Inside gdb_test we will spot the leading '^' in the pattern, and inject the regexp version of the command after the '^', followed by a '\r\n'. My hope is that given this new ability, folk will be more inclined to anchor their output patterns when this makes sense to do so. This should increase our ability to catch any unexpected output from GDB that appears as a result of running a particular command. There is one problem case we need to consider, sometime people do this: gdb_test "" "^expected output pattern" In this case no command is sent to GDB, but we are still expecting some output from GDB. This might be a result of some asynchronous event for example. As there is no command sent to GDB (from the gdb_test) there will be no command text to parse. In this case my proposed new feature injects the command regexp, which is the empty string (as the command itself is empty), but still injects the '\r\n' after the command regexp, thus we end up with this pattern: ^\r\nexpected output pattern This extra '\r\n' is not what we should expected here, and so there is a special case inside gdb_test -- if the command is empty then don't add anything after the '^' character. There are a bunch of tests that do already use '^' followed by the command, and these can all be simplified in this commit. I've tried to run all the tests that I can to check this commit, but I am certain that there will be some tests that I manage to miss. Apologies for any regressions this commit causes, hopefully fixing the regressions will not be too hard. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-04-27gdb/testsuite: change newline patterns used in gdb_testAndrew Burgess1-2/+2
This commit makes two changes to how we match newline characters in the gdb_test proc. First, for the newline pattern between the command output and the prompt, I propose changing from '[\r\n]+' to an explicit '\r\n'. The old pattern would spot multiple newlines, and so there are a few places where, as part of this commit, I've needed to add an extra trailing '\r\n' to the pattern in the main test file, where GDB's output actually includes a blank line. But I think this is a good thing. If a command produces a blank line then we should be checking for it, the current gdb_test doesn't do that. But also, with the current gdb_test, if a blank line suddenly appears in the output, this is going to be silently ignored, and I think this is wrong, the test should fail in that case. Additionally, the existing pattern will happily match a partial newline. There are a strangely large number of tests that end with a random '.' character. Not matching a literal period, but matching any single character, this is then matching half of the trailing newline sequence, while the \[\r\n\]+ in gdb_test is matching the other half of the sequence. I can think of no reason why this would be intentional, I suspect that the expected output at one time included a period, which has since been remove, but I haven't bothered to check on this. In this commit I've removed all these unneeded trailing '.' characters. The basic rule of gdb_test after this is that the expected pattern needs to match everything up to, but not including the newline sequence immediately before the GDB prompt. This is generally how the proc is used anyway, so in almost all cases, this commit represents no significant change. Second, while I was cleaning up newline matching in gdb_test, I've also removed the '[\r\n]*' that was added to the start of the pattern passed to gdb_test_multiple. The addition of this pattern adds no value. If the user pattern matches at the start of a line then this would match against the newline sequence. But, due to the '*', if the user pattern doesn't match at the start of a line then this group doesn't care, it'll happily match nothing. As such, there's no value to it, it just adds more complexity for no gain, so I'm removing it. No tests will need updating as a consequence of this part of the patch. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-04-27gdb/testsuite: use 'return' in gdb_test_no_outputAndrew Burgess1-2/+7
A TCL proc will return the return value of the last command executed within the proc's body if there is no explicit return call, so gdb_test_no_output is already returning the return value of gdb_test_multiple. However, I'm not a fan of (relying on) this implicit return value behaviour -- I prefer to be explicit about what we are doing. So in this commit I have extended the comment on gdb_test_no_output to document the possible return values (just as gdb_test does), and explicitly call return. This should make no different to our testing, but I think it's clearer now what the gdb_test_no_output proc is expected to do. The two tests gdb.base/auxv.exp and gdb.base/list.exp both rely on the return value of gdb_test_no_output, and continue to pass after this change. I also spotted that gdb.base/watchpoint.exp could be updated to make use of gdb_test_no_output, so I did that. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-04-24[gdb/testsuite] Fix -wrap in presence of -prompt in gdb_test_multipleTom de Vries1-1/+1
While writing a gdb_test_multiple call in a test-case I tried to use -wrap in combination with -prompt and found out that it doesn't work, because -wrap uses "$gdb_prompt $" instead of $prompt_regexp. Fix this by making -wrap use $prompt_regexp. Tested on x86_64-linux.
2023-04-24[gdb/testsuite] Fix gdb.multi/multi-arch.exp on powerpc64leTom de Vries1-0/+8
When running test-case gdb.multi/multi-arch.exp on powerpc64le-linux, I run into: ... Running gdb/testsuite/gdb.multi/multi-arch.exp ... gdb compile failed, In file included from /usr/include/features.h:399:0, from /usr/include/stdio.h:27, from gdb/testsuite/gdb.multi/hangout.c:18: /usr/include/gnu/stubs.h:8:27: fatal error: gnu/stubs-32.h: \ No such file or directory # include <gnu/stubs-32.h> ^ compilation terminated. ... The problem is that the test-case attempts to use gcc -m32 to produce an executable while that's not available. Fix this by: - introduce a new caching proc have_compile_and_link_flag, and - using have_compile_and_link_flag in test-case gdb.multi/multi-arch.exp. Tested on: - x86_64-linux (openSUSE Leap 15.4), and - powerpc64le-linux (CentOS-7).
2023-04-24[gdb/testsuite] Add basic lmap for tcl < 8.6Tom de Vries1-0/+15
With test-case gdb.dwarf2/dw2-abs-hi-pc.exp and tcl 8.5, I run into: ... ERROR: tcl error sourcing gdb/testsuite/gdb.dwarf2/dw2-abs-hi-pc.exp. ERROR: invalid command name "lmap" while executing "::gdb_tcl_unknown lmap i {dw2-abs-hi-pc.c dw2-abs-hi-pc-hello.c \ dw2-abs-hi-pc-world.c} { expr { "$srcdir/$subdir/$i" } }" ... Fix this by adding basic lmap support for tcl version < 8.6. Tested on x86_64-linux.
2023-04-24[gdb/testsuite] Skip dap tests for tcl 8.5Tom de Vries1-0/+5
When running the dap tests on a system with tcl 8.5, we run into: ... ERROR: tcl error sourcing gdb/testsuite/gdb.dap/memory.exp. ERROR: bad class "entier": must be alnum, alpha, ascii, control, boolean, \ digit, double, false, graph, integer, list, lower, print, punct, space, \ true, upper, wideinteger, wordchar, or xdigit while executing "string is entier $num" (procedure "num" line 16) invoked from within ... Fix this by: - requiring tcl 8.6 in allow_dap_tests, and - adding the missing require allow_dap_tests in gdb.dap/memory.exp. Tested on x86_64-linux.
2023-04-11gdb/testsuite: fix typo gdb_name_name -> gdb_test_nameAndrew Burgess1-1/+1
Spotted a small typo in gdb_breakpoint proc, we use $gdb_name_name instead of $gdb_test_name in one place. Fixed in this commit.
2023-04-07[gdb/testsuite] Add -q to INTERNAL_GDBFLAGSTom de Vries1-0/+9
Whenever we start gdb in the testsuite, we have the rather verbose: ... $ gdb GNU gdb (GDB) 14.0.50.20230405-git Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) ... This makes gdb.log longer than necessary and harder to read. We do need to test that the output is produced, but that should be limited to one or a few test-cases. Fix this by adding -q to INTERNAL_GDBFLAGS, such that we simply have: ... $ gdb -q (gdb) ... Tested on x86_64-linux.
2023-03-31[gdb/testsuite] Fix gdb.threads/threadapply.exp with editing offTom de Vries1-1/+1
With test-case gdb.threads/threadapply.exp and editing set to on, we have: ... (gdb) define remove^M Type commands for definition of "remove".^M End with a line saying just "end".^M >remove-inferiors 3^M >end^M (gdb) ... but with editing set to off, we run into: ... (gdb) define remove^M Type commands for definition of "remove".^M End with a line saying just "end".^M >remove-inferiors 3^M end^M >(gdb) FAIL: gdb.threads/threadapply.exp: thread_set=all: try remove: \ define remove (timeout) ... The commands are issued by this test: ... gdb_define_cmd "remove" { "remove-inferiors 3" } ... which does: - gdb_test_multiple "define remove", followed by - gdb_test_multiple "remove-inferiors 3\nend". Proc gdb_test_multiple has special handling for multi-line commands, which splits it up into subcommands, and for each subcommand issues it and then waits for the resulting prompt (the secondary prompt ">" for all but the last subcommand). However, that doesn't work as expected in this case because the initial gdb_test_multiple "define remove" fails to match all resulting output, and consequently the secondary prompt resulting from "define remove" is counted as if it was the one resulting from "remove-inferiors 3". Fix this by matching the entire output of "define remove", including the secondary prompt. Tested on x86_64-linux. PR testsuite/30288 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30288
2023-03-29Remove version_at_leastTom Tromey1-15/+3
version_at_least is a less capable variant of version_compare, so this patch removes it.
2023-03-28gdb/testsuite: allow "require" callbacks to provide a reasonSimon Marchi1-8/+29
When an allow_* proc returns false, it can be a bit difficult what check failed exactly, if the procedure does multiple checks. To make investigation easier, I propose to allow the "require" callbacks to be able to return a list of two elements: the zero/non-zero value, and a reason string. Use the new feature in allow_hipcc_tests to demonstrate it (it's also where I hit actually hit this inconvenience). On my computer (where GDB is built with amd-dbgapi support but where I don't have a suitable GPU target), I get: UNSUPPORTED: gdb.rocm/simple.exp: require failed: allow_hipcc_tests (no suitable amdgpu targets found) vs before: UNSUPPORTED: gdb.rocm/simple.exp: require failed: allow_hipcc_tests Change-Id: Id1966535b87acfcbe9eac99f49dc1196398c6578 Approved-By: Tom de Vries <tdevries@suse.de>
2023-03-28[gdb/testsuite] Allow gdb.rust/expr.exp without rust compilerTom de Vries1-4/+0
Proc allow_rust_tests returns 0 when there's no rust compiler, but that gives the wrong answer for gdb.rust/expr.exp, which doesn't require it. Fix this by using can_compile rust in the test-cases that need it, and just returning 1 in allow_rust_tests. Tested on x86_64-linux.
2023-03-28[gdb/testsuite] Add can_compile rustTom de Vries1-23/+42
If I deinstall the rust compiler, I get: ... gdb compile failed, default_target_compile: Can't find rustc --color never. UNTESTED: gdb.rust/watch.exp: failed to prepare ... Fix this by adding can_compile rust, and using it in allow_rust_tests, such that we have instead: ... UNSUPPORTED: gdb.rust/watch.exp: require failed: allow_rust_tests ... Since the rest of the code in allow_rust_tests is also about availability of the rust compiler, move it to can_compile. Tested on x86_64-linux.
2023-03-28[gdb/testsuite] Unsupport gdb.rust for remote hostTom de Vries1-0/+5
With test-case gdb.rust/watch.exp and remote host I run into: ... Executing on host: gcc watch.rs -g -lm -o watch (timeout = 300) ... ld:watch.rs: file format not recognized; treating as linker script ld:watch.rs:1: syntax error ... UNTESTED: gdb.rust/watch.exp: failed to prepare ... The problem is that find_rustc returns "" for remote host, so we fall back to gcc, which fails. Fix this by returning 0 in allow_rust_tests for remote host. Tested on x86_64-linux.
2023-03-27[gdb/testsuite] Fix gdb.dwarf2/gdb-index-cxx.exp for remote hostTom de Vries1-0/+3
Fix test-case gdb.dwarf2/gdb-index-cxx.exp for remote host using host_standard_output_file. Tested on x86_64-linux.
2023-03-27[gdb/testsuite] Fix gdb.dwarf2/gdb-index.exp on remote hostTom de Vries1-1/+6
Fix test-case gdb.dwarf2/gdb-index.exp on remote host using gdb_remote_download and host_standard_output_file. Also declare the test-case unsupported with readnow. Tested on x86_64-linux.
2023-03-27[gdb/testsuite] Fix quoting issues in gdb.dwarf2 for remote hostTom de Vries1-0/+13
A few test-cases in gdb.dwarf2 use something like: ... additional_flags=\"-DFOO=BAR + 10\" ... which doesn't work on remote host. Fix this by introducing a new proc quote_for_host that also works for remote host, such that we have: ... additional_flags=[quote_for_host -DFOO=BAR + 10] ... Tested on x86_64-linux.
2023-03-27[gdb/testsuite] Fix have_index for remote hostTom de Vries1-0/+4
Proc have_index is mostly used with $binfile, which gives problems for remote host. Fix this by using "file tail" on the proc argument. Tested on x86_64-linux.