From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21959 invoked by alias); 6 Jan 2010 20:13:21 -0000 Received: (qmail 21947 invoked by uid 22791); 6 Jan 2010 20:13:19 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Jan 2010 20:13:15 +0000 Received: from mailhost4.vmware.com (mailhost4.vmware.com [10.16.67.124]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 22C2113ECA; Wed, 6 Jan 2010 12:13:14 -0800 (PST) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost4.vmware.com (Postfix) with ESMTP id 180D9C9A22; Wed, 6 Jan 2010 12:13:14 -0800 (PST) Message-ID: <4B44ED79.6010007@vmware.com> Date: Wed, 06 Jan 2010 20:13:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20090624) MIME-Version: 1.0 To: Stan Shebs CC: "tromey@redhat.com" , "gdb-patches@sourceware.org" Subject: Re: [PATCH] Disconnected tracing References: <4B441D89.6030902@codesourcery.com> <4B44EAEF.9040206@codesourcery.com> In-Reply-To: <4B44EAEF.9040206@codesourcery.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-01/txt/msg00124.txt.bz2 Stan Shebs wrote: > Tom Tromey wrote: >>>>>>> "Stan" == Stan Shebs writes: >>>>>>> >> Stan> This next patch realizes a long-anticipated advantage of tracepoints, >> Stan> namely that it should be possible to disconnect GDB from the target >> Stan> but leave the trace experiment running, then reconnect later to see if >> Stan> anything interesting turned up. >> >> A couple little nits... >> >> Stan> + extern void create_tracepoint_from_upload (int num, enum bptype type, >> Stan> + ULONGEST addr); >> >> Could this be in a header? And then the declaration in >> remote_get_tracing_state removed? >> >> Maybe this is another of those "will be fixed by the target vector" >> oddities. >> >> > Yep, this is all going to get churned around by both target vector > changes and uploading rewrite. With unified syntax, the uploading part > (qTfP/qTsP) is part of remote protocol, but the parsing of tracepoint > info fields gets to be generic. This is all so cool! ;-)