From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24564 invoked by alias); 8 Apr 2010 19:10:30 -0000 Received: (qmail 24436 invoked by uid 22791); 8 Apr 2010 19:10:28 -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 19:10:24 +0000 Received: (qmail 32089 invoked from network); 8 Apr 2010 19:10:22 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 8 Apr 2010 19:10:22 -0000 Message-ID: <4BBE2A19.3010604@codesourcery.com> Date: Thu, 08 Apr 2010 19:10:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Pedro Alves CC: Stan Shebs , gdb-patches@sourceware.org Subject: Re: tracing broken if target doesn't do disconnected tracing References: <201004050101.02067.pedro@codesourcery.com> <201004081825.15900.pedro@codesourcery.com> <4BBE1E00.3070306@codesourcery.com> <201004081932.31774.pedro@codesourcery.com> In-Reply-To: <201004081932.31774.pedro@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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/msg00185.txt.bz2 Pedro Alves wrote: > 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. > > Ok, I'm with you now. And you're right, they shouldn't be asymmetrical. Stan