From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22583 invoked by alias); 27 Sep 2013 20:41:36 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 22574 invoked by uid 89); 27 Sep 2013 20:41:36 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Sep 2013 20:41:36 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8RKfXKA010227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 27 Sep 2013 16:41:33 -0400 Received: from psique (ovpn-113-38.phx2.redhat.com [10.3.113.38]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r8RKfTVf022872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 27 Sep 2013 16:41:31 -0400 From: Sergio Durigan Junior To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 2/2] [GDBserver]: Silence exits if GDB is connected through stdio. References: <1380309731-29881-1-git-send-email-palves@redhat.com> <1380309731-29881-3-git-send-email-palves@redhat.com> X-URL: http://www.redhat.com Date: Fri, 27 Sep 2013 20:41:00 -0000 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") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00977.txt.bz2 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 > > * 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