[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

0 files changed, 0 insertions, 0 deletions