This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/2] [GDBserver]: Silence exits if GDB is connected through stdio.
- From: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 27 Sep 2013 17:41:29 -0300
- Subject: Re: [PATCH 2/2] [GDBserver]: Silence exits if GDB is connected through stdio.
- Authentication-results: sourceware.org; auth=none
- References: <1380309731-29881-1-git-send-email-palves at redhat dot com> <1380309731-29881-3-git-send-email-palves at redhat dot com>
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