From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9860 invoked by alias); 5 Apr 2010 01:08:09 -0000 Received: (qmail 9750 invoked by uid 22791); 5 Apr 2010 01:08:08 -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; Mon, 05 Apr 2010 01:08:03 +0000 Received: (qmail 29393 invoked from network); 5 Apr 2010 01:08:02 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Apr 2010 01:08:02 -0000 Message-ID: <4BB937EC.6080303@codesourcery.com> Date: Mon, 05 Apr 2010 01:08:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Pedro Alves CC: gdb-patches@sourceware.org, Stan Shebs Subject: Re: tracing broken if target doesn't do disconnected tracing References: <201004050101.02067.pedro@codesourcery.com> In-Reply-To: <201004050101.02067.pedro@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; 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/msg00070.txt.bz2 Pedro Alves wrote: > The gdbserver tracepoints patch I just posted doesn't > include disconnected tracing yet. Note what > happens then: [...] > > > > This is because common code outside remote.c has no clue > whether the target supports or not disconnected tracing, and > just assumes it does. Exposing that property seems to > conflict a bit with the desire to allow > "set disconnected-tracing on" before actually being connected, > so, I've avoided doing it so far. Maybe we could get away with > a tristate "yes|no|not-known-yet-maybe". > > WDYT? Shall I proceed with this as is? Would you like to > address this? > This is pretty close to what we want, I think; but generic code does need to know about this, so that disconnect_or_stop_tracing can say the right things. For instance, a target that cannot do disconnected tracing should warn that the user that the detach is about to bring an ongoing trace experiment to a halt, and certainly shouldn't tease the user with a query() that can't possibly succeed. I'm thinking that this is in some ways like the circular trace buffer flag, and could be reasonably made accessible via the trace_status structure. Unless you're just dying to do this yourself :-) , I'll take care of the two together. (I can see where this is going longterm - struct trace_status is effectively a host-side copy of the agent's state, echoed back in response to any instructions that GDB sends down.) Stan