summaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.base/run-attach-while-running.exp
Commit message (Collapse)AuthorAgeFilesLines
* [gdb/testsuite] Handle for loop initial decl with gcc 4.8.5Tom de Vries2022-01-031-1/+2
| | | | | | | | | | | | | | | | When running test-case gdb.threads/schedlock-thread-exit.exp on a system with system compiler gcc 4.8.5, I run into: ... src/gdb/testsuite/gdb.threads/schedlock-thread-exit.c:33:3: error: \ 'for' loop initial declarations are only allowed in C99 mode ... Fix this by: - using -std=c99, or - using -std=gnu99, in case that's required, or - in the case of the jit test-cases, rewriting the for loops. Tested on x86_64-linux, both with gcc 4.8.5 and gcc 7.5.0.
* Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker2022-01-011-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.
* gdb/testsuite: make runto_main not pass no-message to runtoSimon Marchi2021-09-301-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | As follow-up to this discussion: https://sourceware.org/pipermail/gdb-patches/2020-August/171385.html ... make runto_main not pass no-message to runto. This means that if we fail to run to main, for some reason, we'll emit a FAIL. This is the behavior we want the majority of (if not all) the time. Without this, we rely on tests logging a failure if runto_main fails, otherwise. They do so in a very inconsisteny mannet, sometimes using "fail", "unsupported" or "untested". The messages also vary widly. This patch removes all these messages as well. Also, remove a few "fail" where we call runto (and not runto_main). by default (without an explicit no-message argument), runto prints a failure already. In two places, gdb.multi/multi-re-run.exp and gdb.python/py-pp-registration.exp, remove "message" passed to runto. This removes a few PASSes that we don't care about (but FAILs will still be printed if we fail to run to where we want to). This aligns their behavior with the rest of the testsuite. Change-Id: Ib763c98c5f4fb6898886b635210d7c34bd4b9023
* [gdb/testsuite] Fix gdb.base/run-attach-while-running.expTom de Vries2021-06-071-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With a testsuite setup modified to make expect wait a little bit longer for gdb output (see PR27957), I reliably run into: ... 27 return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M (gdb) ^M Thread 2 "run-attach-whil" stopped.^M 0x00007f13c85a74c0 in __GI___nanosleep () at nanosleep.c:27^M 27 return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M FAIL: gdb.base/run-attach-while-running.exp: threaded=1: \ run-or-attach=attach: non-stop=on: test: attach to process (timeout) ... The problem is that we're trying to match the gdb_prompt using gdb_test which uses '$gdb_prompt $'. The terminating '$' prevents the match. Fix this by rewriting the gdb_test into a gdb_test_multiple and dropping the '$'. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-06-07 Tom de Vries <tdevries@suse.de> PR testsuite/27908 * gdb.base/run-attach-while-running.exp (test): Don't match prompt after attach using '$gdb_prompt $'.
* gdb/testsuite: add test for run/attach while program is runningSimon Marchi2021-03-171-0/+120
A WIP patch series broke the use case of doing "run" or "attach" while the program is running, but it wasn't caught by the testsuite, which means it's not covered. Add a test for that. gdb/testsuite/ChangeLog: * gdb.base/run-attach-while-running.exp: New. * gdb.base/run-attach-while-running.c: New. Change-Id: I77f098ec0b28dc2d4575ea80e941f6a75273e431