Fix latent bug in default_prompt_gdb_start

default_prompt_gdb_start mimics default_gdb_start, but does not set
the use_gdb_stub global.  This caused one Python test to work only
because it used the ordinary gdb_start before later using
default_prompt_gdb_start.

This patch updates default_prompt_gdb_start to set this global as
well.

diff --git a/gdb/testsuite/lib/prompt.exp b/gdb/testsuite/lib/prompt.exp
index a7c34fae2ec367140023b945cd2445888683bad1..56cafa4dd938db3adea080d57039f4f45bf9f214 100644 (file)
--- a/gdb/testsuite/lib/prompt.exp
+++ b/gdb/testsuite/lib/prompt.exp
@@ -24,6 +24,7 @@
 # uses pass if it sees $gdb_prompt, and fail if it sees $gdb_prompt_fail.
 #
 proc default_prompt_gdb_start { } {
+    global use_gdb_stub
     global GDB
     global INTERNAL_GDBFLAGS GDBFLAGS
     global gdb_prompt
@@ -31,7 +32,17 @@ proc default_prompt_gdb_start { } {
     global timeout
     global gdb_spawn_id
 
+    # Set the default value, it may be overriden later by specific testfile.
+    #
+    # Use `set_board_info use_gdb_stub' for the board file to flag the inferior
+    # is already started after connecting and run/attach are not supported.
+    # This is used for the "remote" protocol.  After GDB starts you should
+    # check global $use_gdb_stub instead of the board as the testfile may force
+    # a specific different target protocol itself.
+    set use_gdb_stub [target_info exists use_gdb_stub]
+
     verbose "Spawning $GDB $INTERNAL_GDBFLAGS $GDBFLAGS"
+    gdb_write_cmd_file "$GDB $INTERNAL_GDBFLAGS $GDBFLAGS"
 
     if [info exists gdb_spawn_id] {
        return 0