From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11492 invoked by alias); 17 Mar 2010 16:55:55 -0000 Received: (qmail 11483 invoked by uid 22791); 17 Mar 2010 16:55:54 -0000 X-SWARE-Spam-Status: No, hits=-2.4 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:55:50 +0000 Received: (qmail 28875 invoked from network); 17 Mar 2010 16:55:48 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 17 Mar 2010 16:55:48 -0000 Message-ID: <4BA1098A.6020800@codesourcery.com> Date: Wed, 17 Mar 2010 16:55:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Pedro Alves CC: gdb-patches@sourceware.org, Stan Shebs Subject: Re: PATCH: Circular trace buffers References: <4B9FFB2A.4080205@codesourcery.com> <201003171600.46751.pedro@codesourcery.com> In-Reply-To: <201003171600.46751.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-03/txt/msg00625.txt.bz2 Pedro Alves wrote: > 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. Hey Joel, pass me that aspirin bottle, willya? :-) This is one of those places where I'd like more user feedback before getting too fancy. It's the opposite situation of expression evaluation - we play fast and loose with language semantics, but we know from extensive experience that users don't want GDB to be too pedantic about visibility, scopes, etc. But for tracepoints we're still mostly guessing. > 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. I thought about that, but it seemed like one of its uses would be as a hasty way to keep a trace run alive; you do a tstatus, say "oh sh*t" as you see the buffer at 80% full before you've reached the code of interest, and quickly switch to circular buffer. > - 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. > I think the user would know to interrupt the program, because there's no prompt to type the command at? > - 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. > You would know if circularity had kicked in because tstatus on the file would show more frames created than were in the buffer. If it hadn't kicked in, then the flag's value wouldn't be of much interest, right? Stan