This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/2] [GDBserver]: Silence exits if GDB is connected through stdio.


On Friday, September 27 2013, Pedro Alves wrote:

> After the previous patch, catch-syscall.exp still doesn't pass with
> the native-stdio-gdbserver.exp board.  We get:
>
>  (gdb) continue
>  Continuing.
>
>  Child exited with status 0
>  GDBserver exiting
>  [Inferior 1 (process 22721) exited normally]
>  (gdb) FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
>
> The problem is the whole "Child exited ... GDBserver exiting" output,
> that comes out of GDBserver, and that the testsuite is not expecting.

FWIW, I agree with this patch.  I hadn't tested catch syscall using
neither native{,-stdio}-gdbserver, so I didn't catch those errors.
Sorry about that.

> In fact, the previous patch adds a bunch of regressions with this
> board due to this, not just to catch-syscall.exp:
>
> -PASS: gdb.arch/amd64-disp-step.exp: continue until exit at amd64-disp-step
> +FAIL: gdb.arch/amd64-disp-step.exp: continue until exit at amd64-disp-step (the program exited)
> -PASS: gdb.base/break.exp: continue until exit at recursive next test
> +FAIL: gdb.base/break.exp: continue until exit at recursive next test (the program exited)
> -PASS: gdb.base/chng-syms.exp: continue until exit at breakpoint first time through
> +FAIL: gdb.base/chng-syms.exp: continue until exit at breakpoint first time through (the program exited)
> ... etc. ...
>
> (I plan to swap the order of the patches before check in, to prevent
> breaking bisects.)
>
> I pondered somehow making the testsuite adjust to this.  But,
> testsuite aside, I think GDBserver should not be outputting this at
> all when GDB is connected through stdio.  GDBserver will be printing
> this in GDB's console, but the user can already tell from the regular
> output that the inferior is gone.
>
> Again, manually:
>
>  (gdb) tar remote | ./gdbserver/gdbserver - program
>  Remote debugging using | ./gdbserver/gdbserver - program
>  Process program created; pid = 22486
>  stdin/stdout redirected
>  Remote debugging using stdio
>  done.
>  Loaded symbols for /lib64/ld-linux-x86-64.so.2
>  0x000000323d001530 in _start () from /lib64/ld-linux-x86-64.so.2
>  (gdb) c
>  Continuing.
>  Child exited with status 1
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^
>  GDBserver exiting
>  ^^^^^^^^^^^^^^^^^
>  [Inferior 1 (process 22486) exited with code 01]
>  (gdb)
>
> Suppressing those two lines makes the output be exactly like when
> debugging against a remote tcp gdbserver:
>
>  (gdb) c
>  Continuing.
>  [Inferior 1 (process 22914) exited with code 01]
>  (gdb)
>
> Comments?

Patch is fine by me, thanks!

> 2013-09-27  Pedro Alves  <palves@redhat.com>
>
> 	* server.c (process_serial_event): Don't output "GDBserver
> 	exiting" if GDB is connected through stdio.
> 	* target.c (mywait): Likewise, be silent if GDB is connected
> 	through stdio.
> ---
>  gdb/gdbserver/server.c |  5 ++++-
>  gdb/gdbserver/target.c | 23 ++++++++++++++++-------
>  2 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/gdb/gdbserver/server.c b/gdb/gdbserver/server.c
> index 4de20d5..e0af785 100644
> --- a/gdb/gdbserver/server.c
> +++ b/gdb/gdbserver/server.c
> @@ -3550,7 +3550,10 @@ process_serial_event (void)
>  	 the whole vStopped list (until it gets an OK).  */
>        if (QUEUE_is_empty (notif_event_p, notif_stop.queue))
>  	{
> -	  fprintf (stderr, "GDBserver exiting\n");
> +	  /* Be transparent when GDB is connected through stdio -- no
> +	     need to spam GDB's console.  */
> +	  if (!remote_connection_is_stdio ())
> +	    fprintf (stderr, "GDBserver exiting\n");
>  	  remote_close ();
>  	  exit (0);
>  	}
> diff --git a/gdb/gdbserver/target.c b/gdb/gdbserver/target.c
> index 1a0dee2..64940e2 100644
> --- a/gdb/gdbserver/target.c
> +++ b/gdb/gdbserver/target.c
> @@ -82,13 +82,22 @@ mywait (ptid_t ptid, struct target_waitstatus *ourstatus, int options,
>  
>    ret = (*the_target->wait) (ptid, ourstatus, options);
>  
> -  if (ourstatus->kind == TARGET_WAITKIND_EXITED)
> -    fprintf (stderr,
> -	     "\nChild exited with status %d\n", ourstatus->value.integer);
> -  else if (ourstatus->kind == TARGET_WAITKIND_SIGNALLED)
> -    fprintf (stderr, "\nChild terminated with signal = 0x%x (%s)\n",
> -	     gdb_signal_to_host (ourstatus->value.sig),
> -	     gdb_signal_to_name (ourstatus->value.sig));
> +  /* If GDB is connected through TCP/serial, then GDBserver will most
> +     probably be running on its own terminal/console, so it's nice to
> +     print there why is GDBserver existing.  If however, GDB is
> +     connected through stdio, then there's no need to spam the GDB
> +     console with this -- the user will already see the exit through
> +     regular GDB output, in that same terminal.  */
> +  if (!remote_connection_is_stdio ())
> +    {
> +      if (ourstatus->kind == TARGET_WAITKIND_EXITED)
> +	fprintf (stderr,
> +		 "\nChild exited with status %d\n", ourstatus->value.integer);
> +      else if (ourstatus->kind == TARGET_WAITKIND_SIGNALLED)
> +	fprintf (stderr, "\nChild terminated with signal = 0x%x (%s)\n",
> +		 gdb_signal_to_host (ourstatus->value.sig),
> +		 gdb_signal_to_name (ourstatus->value.sig));
> +    }
>  
>    if (connected_wait)
>      server_waiting = 0;
> -- 
> 1.7.11.7

-- 
Sergio


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]