aboutsummaryrefslogtreecommitdiff
path: root/gdb
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2025-06-24 17:17:38 +0200
committerTom de Vries <tdevries@suse.de>2025-06-24 17:17:38 +0200
commit3b5b306522f748f2e384e58cf5dc046346f84dcb (patch)
treec60367c13ac2d58345bcaf7a3773bd693475f9f1 /gdb
parent744dabeb29d6fb07f3fe7d91031adc5c85b7f865 (diff)
downloadbinutils-3b5b306522f748f2e384e58cf5dc046346f84dcb.zip
binutils-3b5b306522f748f2e384e58cf5dc046346f84dcb.tar.gz
binutils-3b5b306522f748f2e384e58cf5dc046346f84dcb.tar.bz2
[gdb/testsuite] Make gdb.dap/log-message.exp more robust
PR testsuite/31831 reports the following failure in the gdb.dap/log-message.exp test-case (formatted for readability): ... { "type": "event", "event": "output", "body": { "category": "stdout", "output": "Breakpoint 1 at 0x681: file log-message.c, line 23.\n" }, "seq": 13 } FAIL: $exp: logging output (checking body category) ... for a gdb 14.2 based package. The output event listed above is a result from the setBreakpoints request. The test-case issues the setBreakpoints request and waits for the corresponding response, but doesn't wait for the output event, and consequently the output event is read by: ... dap_wait_for_event_and_check "logging output" output \ {body category} console \ {body output} "got 23 - 23 = 0" ... which triggers the failure. I'm not able to reproduce this, but it looks worth fixing regardless. We're fixing this on trunk though, and the output event looks different, and there's one more output event: ... { "type": "event", "event": "output", "body": { "category": "stdout", "output": "No source file named log-message.c.\n" }, "seq": 4 } { "type": "event", "event": "output", "body": { "category": "stdout", "output": "Breakpoint 1 (-source log-message.c -line 23) pending.\n" }, "seq": 5 } ... Fix this by waiting for these two output events, making the test-case a bit more robust. It is possible that one or both of these output events will be read by dap_check_request_and_response "set breakpoint", and in that case restashing them (for which there's currently no infrastructure) would be an easy way of handling this. But I haven't been able to trigger that, so I'm leaving that for if and when it does. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31831
Diffstat (limited to 'gdb')
-rw-r--r--gdb/testsuite/gdb.dap/log-message.exp9
1 files changed, 9 insertions, 0 deletions
diff --git a/gdb/testsuite/gdb.dap/log-message.exp b/gdb/testsuite/gdb.dap/log-message.exp
index 421df14..cce367d 100644
--- a/gdb/testsuite/gdb.dap/log-message.exp
+++ b/gdb/testsuite/gdb.dap/log-message.exp
@@ -40,6 +40,15 @@ set obj [dap_check_request_and_response "set breakpoint" \
[list s $srcfile] $line]]
set fn_bpno [dap_get_breakpoint_number $obj]
+set eol {\n}
+dap_wait_for_event_and_check "set breakpoint output, part 1" output \
+ {body category} stdout \
+ {body output} "No source file named log-message.c.$eol"
+
+dap_wait_for_event_and_check "set breakpoint output, part 2" output \
+ {body category} stdout \
+ {body output} "Breakpoint 1 (-source log-message.c -line $line) pending.$eol"
+
dap_check_request_and_response "configurationDone" configurationDone
dap_check_response "launch response" launch $launch_id