From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27195 invoked by alias); 8 Apr 2010 17:25:25 -0000 Received: (qmail 27183 invoked by uid 22791); 8 Apr 2010 17:25:24 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 08 Apr 2010 17:25:19 +0000 Received: (qmail 31681 invoked from network); 8 Apr 2010 17:25:18 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 8 Apr 2010 17:25:18 -0000 From: Pedro Alves To: Stan Shebs Subject: Re: tracing broken if target doesn't do disconnected tracing Date: Thu, 08 Apr 2010 17:25:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <201004050101.02067.pedro@codesourcery.com> <201004071435.39891.pedro@codesourcery.com> <4BBD0176.6060409@codesourcery.com> In-Reply-To: <4BBD0176.6060409@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201004081825.15900.pedro@codesourcery.com> X-IsSubscribed: yes 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 X-SW-Source: 2010-04/txt/msg00181.txt.bz2 On Wednesday 07 April 2010 23:04:38, Stan Shebs wrote: > Pedro Alves wrote: > > > I suggest we change that to simply: > > > > /* If running interactively, warn the user a trace run is ongoing. > > She may want to cancel detaching instead. */ > > if (current_trace_status ()->running && from_tty) > > { > > if (current_trace_status ()->disconnected_tracing) > > { > > if (!query (_("Trace is running and will continue after detach; detach anyway? "))) > > error (_("Not confirmed.")); > > } > > else > > { > > if (!query (_("Trace is running but will stop on detach; detach anyway? "))) > > error (_("Not confirmed.")); > > } > > } > > > > - simpler, more coherent, less explaining, less confusing. > > > > The downside of this design is that if you did want to shut tracing > down, you have to cancel the detach, do a tstop, then redo the detach. > It's not crucial perhaps, but it seems a bit pedantic for GDB to have > the power to choose whether to keep the trace running, but not to > exercise it, and to insist that you have cancel and type the command > yourself. Perhaps the crux of the confusion is that this is really a > three-way choice - trace/detach, tstop/detach, cancel - and a pair of > yes/no questions is not a good way to model it. That's just begging for: The downside of your current design is that if you did want to detach and leave tracing running, you have to cancel the detach, do a "set disconnected-tracing on", then redo the detach. It's not crucial perhaps, but it seems a bit pedantic for GDB to have the power to choose whether to keep the trace running, but not to exercise it, and to insist that you have cancel and type the command yourself. :-) I'd say that this use case would be much more common, and if gdb gave you the option of turning disconnected tracing _on_ would be more helpful than the other way around (having trace running and wanting it to stop on detach). After having used tracing for a while (granted, not really in the field), I believe that this "do you want to stop tracing" query will get old soon. But, I can see that I can't manage to convince you of anything, so please, let's not get stuck on this issue, and let's move forward with whatever you think is right. -- Pedro Alves