From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27248 invoked by alias); 17 Mar 2010 16:00:59 -0000 Received: (qmail 27221 invoked by uid 22791); 17 Mar 2010 16:00:56 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 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, 17 Mar 2010 16:00:50 +0000 Received: (qmail 25770 invoked from network); 17 Mar 2010 16:00:48 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 17 Mar 2010 16:00:48 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: PATCH: Circular trace buffers Date: Wed, 17 Mar 2010 16:00:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-19-generic; KDE/4.3.2; x86_64; ; ) Cc: Stan Shebs References: <4B9FFB2A.4080205@codesourcery.com> In-Reply-To: <4B9FFB2A.4080205@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201003171600.46751.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-03/txt/msg00621.txt.bz2 On Tuesday 16 March 2010 21:42:02, Stan Shebs wrote: > This patch adds a flag that requests the target agent to make the trace > buffer circular, so that instead of filling it up and then stopping, the > agent discards the oldest trace frames as necessary to accommodate new > ones. Any hairy memory management code is going to be on the target > side; GDB just has to transmit the setting (and now always via target > vector), and report back status, which may now include a total number of > frames that were created. This also adds complete documentation of the > qTStatus reply, per request. Any comments before I commit? Playing devil's advogate here, I'm still not 100% convinced that "set circular-trace-buffer" is 100% well defined and that is isn't confusing in some cases; it applies on the fly in some cases, does somewhat not-completly clear things in other cases, and errors out in others. I wonder if we defined "set circular-trace-buffer" as another flag that is respected at "tstart" time only, and made the presently running trace run's circular-trace-buffer-ness reported through "tstatus", and define "show circular-trace-buffer" as the "circular-trace-buffer-ness" intent at next trace run start, things would be more consistent and clear. If not, vis.: E.g., - applies on the fly in non-stop mode. - all-stop/async + trace running + "set circular-trace-buffer" errors out because you can't talk to the target if it is running in all-stop. - E.g., what does "show circular-trace-buffer" mean when debugging a tfile? "set circular-trace-buffer" changes the local GDB flag, and "show circular-trace-buffer" shows the according change, but, then we have no way of knowing when debugging a tfile had been in circular-trace-buffer mode or not when the tfile was created. That said, I'm not opposed to the patch. Just dumping my thoughts. :-) -- Pedro Alves