Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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