[binutils-gdb] [gdb/testsuite] Make gdb.dap/log-message.exp more robust

[Tom de Vries]

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3b5b306522f748f2e384e58cf5dc046346f84dcb

commit 3b5b306522f748f2e384e58cf5dc046346f84dcb
Author: Tom de Vries <tdevries@suse.de>
Date:   Tue Jun 24 17:17:38 2025 +0200

    [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

Diff:
---
 gdb/testsuite/gdb.dap/log-message.exp | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/gdb/testsuite/gdb.dap/log-message.exp b/gdb/testsuite/gdb.dap/log-message.exp
index 421df144e6c..cce367d2372 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