aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.base/valgrind-infcall-2.exp
AgeCommit message (Collapse)AuthorFilesLines
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
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-01-25Use require with is_remoteTom Tromey1-4/+1
This changes some tests to use require with 'is_remote', rather than an explicit test. This adds uniformity helps clean up more spots where a test might exit early without any notification.
2023-01-13Rename to allow_xml_testTom Tromey1-1/+1
This changes gdb_skip_xml_test to invert the sense, and renames it to allow_xml_test.
2023-01-13Change 'require' to accept a list of predicatesTom Tromey1-1/+1
This changes 'require' to accept a list of simple predicates. For now, each predicate is just the name of a proc, optionally prefixed with "!" to indicate that the result should be inverted. It's possible to make this fancier, but so far I haven't done so. One idea I had is to allow a predicate to have associated text to display on failure. Another is to convert the predicates that need a running gdb (e.g., skip_python_tests) to start their own gdb, and then 'require' could enforce the rule that gdb not be running when it is called.
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
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-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
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-10-11[gdb/testsuite] Add proc require in lib/gdb.expTom de Vries1-5/+2
Add a new proc require in lib/gdb.exp, and use it to shorten: ... if { [gdb_skip_xml_test] } { # Valgrind gdbserver requires gdb with xml support. untested "missing xml support" return 0 } ... into: ... require gdb_skip_xml_test 0 ... Tested on x86_64-linux, both with and without a trigger patch that forces gdb_skip_xml_test to return 1.
2021-09-30[gdb/testsuite] Add untested for missing xml support in gdb.base/valgrind*.expTom de Vries1-0/+1
Add untested in case missing xml support is detected in test-cases gdb.base/valgrind*.exp. Tested on x86_64-linux.
2021-09-29[gdb/testsuite] Disable vgdb tests if xml not supportedTom de Vries1-0/+5
I build gdb without xml support using --without-expat, and ran into: ... (gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=22032^M Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=22032^M relaying data between gdb and process 22032^M warning: Can not parse XML target description; XML support was disabled at \ compile time^M ... (gdb) PASS: gdb.base/valgrind-infcall.exp: continue #1 p gdb_test_infcall ()^M Remote 'g' packet reply is too long (expected 560 bytes, got 800 bytes): ...^M (gdb) FAIL: gdb.base/valgrind-infcall.exp: p gdb_test_infcall () ... After googling the error message with context valgrind gdbserver, I found indications that the Remote 'g' packet reply error is due to missing xml support. And here ( https://www.valgrind.org/docs/manual/manual-core-adv.html ) I found: ... GDB version needed for ARM and PPC32/64. You must use a GDB version which is able to read XML target description sent by a gdbserver. This is the standard setup if GDB was configured and built with the "expat" library. If your GDB was not configured with XML support, it will report an error message when using the "target" command. Debugging will not work because GDB will then not be able to fetch the registers from the Valgrind gdbserver. ... So I guess I'm running into the same problem for x86_64. Fix this by skipping all gdb.base/valgrind-*.exp tests if xml support is not available. Although only the gdb.base/valgrind-infcall*.exp produce fails, the Remote 'g' packet reply error occurs in all tests, so it seems prudent to disable them all. Tested on x86_64-linux.
2021-01-01Update copyright year range in all GDB filesJoel Brobecker1-1/+1
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-07-20[gdb/testsuite] Fix valgrind-infcall-2.exp without libc debug infoTom de Vries1-1/+1
When running test-case gdb.base/valgrind-infcall-2.exp on a system without libc debug info installed, I run into: ... (gdb) p printf ("bla")^M 'printf' has unknown return type; cast the call to its declared return type^M (gdb) FAIL: gdb.base/valgrind-infcall-2.exp: do printf ... Fix this by casting the result of the printf call to int. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-20 Tom de Vries <tdevries@suse.de> * gdb.base/valgrind-infcall-2.exp: Handle printf unknown return type.
2020-07-17[gdb/testsuite] Add gdb.base/valgrind-infcall-2.expTom de Vries1-0/+75
In commit ee3c5f8968 "Fix GDB crash when registers cannot be modified", we fix a GDB crash: ... $ valgrind /usr/bin/sleep 10000 ==31595== Memcheck, a memory error detector ==31595== Command: /usr/bin/sleep 10000 ==31595== $ gdb /usr/bin/sleep (gdb) target remote | vgdb --pid=31595 Remote debugging using | vgdb --pid=31595 ... $hex in __GI___nanosleep () at nanosleep.c:27 27 return SYSCALL_CANCEL (nanosleep, requested_time, remaining); (gdb) p printf ("bla") terminate called after throwing an instance of 'gdb_exception_error' Aborted (core dumped) ... This patch adds a test-case for it. Unfortunately, I was not able to trigger the error condition using a regular vgdb_start, so I've added a parameter active_at_startup, and when set to 0 this causes valgrind to be started without --vgdb-error=0. Tested on x86_64-linux. Tested with the commit mentioned above reverted, resulting in: ... (gdb) p printf ("bla")^M terminate called after throwing an instance of 'gdb_exception_error'^M ERROR: GDB process no longer exists GDB process exited with wait status 6152 exp10 0 0 CHILDKILLED SIGABRT SIGABRT UNRESOLVED: gdb.base/valgrind-infcall-2.exp: do printf ... gdb/testsuite/ChangeLog: 2020-07-17 Tom de Vries <tdevries@suse.de> * gdb.base/valgrind-infcall-2.c: New test. * gdb.base/valgrind-infcall-2.exp: New file. * lib/valgrind.exp (vgdb_start): Add and handle active_at_startup.