From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22113 invoked by alias); 7 Apr 2010 13:33:01 -0000 Received: (qmail 22103 invoked by uid 22791); 7 Apr 2010 13:33:00 -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; Wed, 07 Apr 2010 13:32:56 +0000 Received: (qmail 21279 invoked from network); 7 Apr 2010 13:32:55 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 7 Apr 2010 13:32:55 -0000 Message-ID: <4BBC8981.4050900@codesourcery.com> Date: Wed, 07 Apr 2010 13:33: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> <201004051204.25151.pedro@codesourcery.com> <4BBBE114.3030305@codesourcery.com> <201004071240.36873.pedro@codesourcery.com> In-Reply-To: <201004071240.36873.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/msg00126.txt.bz2 Pedro Alves wrote: > The support for the feature is reported by qSupported, hence it's > certainly target-wide noawadays. It may or not be desirable to > be able to select which processes keep tracing on disconnect, so > a per-status state flag for that also sounds acceptable --- it > could represent whether tracing will continue for a given process > after disconnection. The flag (trace_status->disconnected_tracing) > being 0 doesn't mean the target doesn't support disconnected > tracing, so there's still no way for the common code to know it. > In a way, what the user wants to know is what qSupported reports, dressed up in a reasonable fashion. Our traditional expectation has been the user knows already, because, well, it's the user's program and the user's hardware. But as the target gets more elaborate - and tracepoint support is certainly a quantum jump in that direction :-) - that assumption breaks down. In that vein, you may recall that one of our upcoming enhancements is to attach an arbitrary text string to a trace run, with the intended purpose of including things like a name and phone number, so that someone else connecting to the target can have a way to find out about the trace run, and know whether it's OK to mess with it. > With the current patch, against the gdbserver that doesn't > support disconnected tracing, I still see this: > > (gdb) set disconnected-tracing on > warning: Target does not support disconnected tracing. > (gdb) show disconnected-tracing > Whether tracing continues after GDB disconnects is on. > > (yes, I wrote the warning, but it was a hack needed before > so that quitting wouldn't get stuck.) > > With a user hat on, the "Whether tracing continues after > GDB disconnects is on." string as above looks confusing > to me. Same, or worse for the circular-trace-buffer > setting, as that one says "target's use of", which isn't > true, it's solely GDB's intention. > > Is there a way to make this pattern unconfusing? We're > going to grow more similar options in the future, and > this will proliferate if unattended. > > Yeah, it's been troubling me too. User-settable variables are GDB's traditional way of instructing GDB about user preferences, but the canned method of phrase construction is too lame to express what is really going on, which is "I prefer that targets to continue tracing after disconnect, whether or not the current target can actually do so". We could use something other than set/show, or invent a better method to produce output - there are other set/shows for which the verbiage is rather contorted. Stan