public inbox for gdb-cvs@sourceware.org
help / color / mirror / Atom feed
* [binutils-gdb] [gdb/testsuite] Fix silent timeouts in gdb.mi/mi-exec-run.exp with remote host
@ 2022-10-27 14:53 Tom de Vries
  0 siblings, 0 replies; only message in thread
From: Tom de Vries @ 2022-10-27 14:53 UTC (permalink / raw)
  To: gdb-cvs

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

commit 6b839dd3deea4de278ebd862edb9c91d335d63e2
Author: Tom de Vries <tdevries@suse.de>
Date:   Thu Oct 27 16:53:12 2022 +0200

    [gdb/testsuite] Fix silent timeouts in gdb.mi/mi-exec-run.exp with remote host
    
    I noticed that running test-case gdb.mi/mi-exec-run.exp with host board
    local-remote-host.exp takes about 44 seconds.
    
    I found two silent timeouts responsible for this.
    
    The first is in mi_gdb_exit, where we have:
    ...
        if { [is_remote host] && [board_info host exists fileid] } {
            send_gdb "999-gdb-exit\n"
            gdb_expect 10 {
                -re "y or n" {
                    send_gdb "y\n"
                    exp_continue
                }
                -re "Undefined command.*$gdb_prompt $" {
                    send_gdb "quit\n"
                    exp_continue
                }
                -re "DOSEXIT code" { }
            }
        }
    ...
    so in gdb.log we see:
    ...
    999-gdb-exit^M
    999^exit^M
    =thread-exited,id="1",group-id="i1"^M
    =thread-group-exited,id="i1"^M
    ...
    after which expect just waits for the timeout.
    
    Fix this by adding a gdb_expect clause to parse the exit:
    ...
                -re "\r\n999\\^exit\r\n" { }
    ...
    
    Note that we're not parsing the thread-exited/thread-group-exited messages, because
    they may not be present:
    ...
    $ gdb -i=mi
    =thread-group-added,id="i1"
    (gdb)
    999-gdb-exit
    999^exit
    $
    ...
    
    After fixing that, we have:
    ...
    (gdb) ^M
    saw mi error
    PASS: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: \
      force-fail=1: run failure detected
    quit^M
    &"quit\n"^M
    ...
    
    What seems to be happening is that default_gdb_exit sends a cli interpreter
    quit command to an mi interpreter, after which again expect just waits for the
    timeout.
    
    Fix this by adding mi_gdb_exit to the end of the test-case, as in many other
    gdb.mi/*.exp test-cases.
    
    After these two fixes, the test-case takes about 4 seconds.
    
    Tested on x86_64-linux.

Diff:
---
 gdb/testsuite/gdb.mi/mi-exec-run.exp | 2 ++
 gdb/testsuite/lib/mi-support.exp     | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.mi/mi-exec-run.exp b/gdb/testsuite/gdb.mi/mi-exec-run.exp
index 3b373b2c84d..01f52e22578 100644
--- a/gdb/testsuite/gdb.mi/mi-exec-run.exp
+++ b/gdb/testsuite/gdb.mi/mi-exec-run.exp
@@ -180,3 +180,5 @@ foreach_with_prefix inferior-tty {"main" "separate"} {
 	}
     }
 }
+
+mi_gdb_exit
diff --git a/gdb/testsuite/lib/mi-support.exp b/gdb/testsuite/lib/mi-support.exp
index e537d3b546b..b11457693be 100644
--- a/gdb/testsuite/lib/mi-support.exp
+++ b/gdb/testsuite/lib/mi-support.exp
@@ -83,7 +83,7 @@ proc mi_uncatched_gdb_exit {} {
 		exp_continue
 	    }
 	    -re "DOSEXIT code" { }
-	    default { }
+	    -re "\r\n999\\^exit\r\n" { }
 	}
     }

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2022-10-27 14:53 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-27 14:53 [binutils-gdb] [gdb/testsuite] Fix silent timeouts in gdb.mi/mi-exec-run.exp with remote host Tom de Vries

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).