From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21173 invoked by alias); 8 Apr 2010 18:32:39 -0000 Received: (qmail 21165 invoked by uid 22791); 8 Apr 2010 18:32:39 -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 18:32:35 +0000 Received: (qmail 8403 invoked from network); 8 Apr 2010 18:32:33 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 8 Apr 2010 18:32:33 -0000 From: Pedro Alves To: Stan Shebs Subject: Re: tracing broken if target doesn't do disconnected tracing Date: Thu, 08 Apr 2010 18:32: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> <201004081825.15900.pedro@codesourcery.com> <4BBE1E00.3070306@codesourcery.com> In-Reply-To: <4BBE1E00.3070306@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201004081932.31774.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/msg00183.txt.bz2 On Thursday 08 April 2010 19:18:40, Stan Shebs wrote: > >> 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. > > > > :-) > > > > Um, I must be missing the joke, it looks like you cut-n-pasted verbatim? Your patch only asks the user whether she wants to leave tracing on or stop it when "set disconnected-tracing" was on. If it was "off" (the user forgot to set it on, as it is off by default), you still have to cancel the detach and issue a "set disconnected-tracing on" command. The joke was that your words only justify one of the branches in your code, and can be used to justify my point in the other branch. Compare the first sentences. As is, your patch doesn't expose GDB's power to turn disconnected-tracing _on_, only _off_. Following your mental model, a user would be much more thankful if gdb offered the ability to turn it on, on the spot. -- Pedro Alves