From: Sergio Durigan Junior <sergiodj@redhat.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 2/2] [GDBserver]: Silence exits if GDB is connected through stdio.
Date: Fri, 27 Sep 2013 20:41:00 -0000 [thread overview]
Message-ID: <m3fvsqc806.fsf@redhat.com> (raw)
In-Reply-To: <1380309731-29881-3-git-send-email-palves@redhat.com> (Pedro Alves's message of "Fri, 27 Sep 2013 20:22:11 +0100")
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
next prev parent reply other threads:[~2013-09-27 20:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-27 19:22 [PATCH 0/2] Make catch-syscall.exp work with "target remote" Pedro Alves
2013-09-27 19:22 ` [PATCH 2/2] [GDBserver]: Silence exits if GDB is connected through stdio Pedro Alves
2013-09-27 20:41 ` Sergio Durigan Junior [this message]
2013-10-02 11:49 ` Pedro Alves
2013-09-27 19:22 ` [PATCH 1/2] Make catch-syscall.exp work with "target remote". A.k.a., teach the testsuite that GDBserver reliably reports program exits Pedro Alves
2013-10-02 11:51 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3fvsqc806.fsf@redhat.com \
--to=sergiodj@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox