Fix "run" failure handling with GDBserver

If starting the inferior process with "run" (vRun packet) fails,
GDBserver throws an error that escapes all the way to the top level.
When an error escapes all the way like that, GDBserver interprets it
as a disconnection, and either goes back to waiting for a new GDB
connection, or exits, if --once was specified.

E.g., with the testcase program added by this commit, we see:

On GDB side:

 ...
 (gdb) tar extended-remote :999
 ...
 Remote debugging using :9999
 (gdb) r
 Starting program:
 Running ".../gdb.base/run-fail-twice/run-fail-twice.nox" on the remote target failed
 (gdb)

On GDBserver side:

 $ gdbserver --once --multi :9999
 Remote debugging from host 127.0.0.1, port 34344
 bash: line 1: .../gdb.base/run-fail-twice/run-fail-twice.nox: Permission denied
 bash: line 1: exec: .../gdb.base/run-fail-twice/run-fail-twice.nox: cannot execute: Permission denied
 gdbserver: During startup program exited with code 126.
 $   # gdbserver exited

This is wrong, as we've connected with extended-remote/--multi.
GDBserver should just report an error to vCont, and continue connected
to GDB, waiting for other commands.

This commit fixes GDBserver by catching the error locally in
handle_v_run.

Change-Id: Ib386f267522603f554b52a885b15229c9639e870
Approved-By: Tom Tromey <tom@tromey.com>

1 files changed, 9 insertions, 1 deletions

diff --git a/gdbserver/server.cc b/gdbserver/server.cc
index c7d5cc1..b170da4 100644
--- a/gdbserver/server.cc
+++ b/gdbserver/server.cc
@@ -3427,7 +3427,15 @@ handle_v_run (char *own_buf)
   free_vector_argv (program_args);
   program_args = new_argv;
 
-  target_create_inferior (program_path.get (), program_args);
+  try
+    {
+      target_create_inferior (program_path.get (), program_args);
+    }
+  catch (const gdb_exception_error &exception)
+    {
+      sprintf (own_buf, "E.%s", exception.what ());
+      return;
+    }
 
   if (cs.last_status.kind () == TARGET_WAITKIND_STOPPED)
     {