From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 701 invoked by alias); 18 Mar 2010 22:14:38 -0000 Received: (qmail 522 invoked by uid 22791); 18 Mar 2010 22:14:36 -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; Thu, 18 Mar 2010 22:14:32 +0000 Received: (qmail 6737 invoked from network); 18 Mar 2010 22:14:30 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Mar 2010 22:14:30 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: PATCH: Circular trace buffers Date: Thu, 18 Mar 2010 22:14: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> <4BA119C4.9080307@codesourcery.com> <201003171851.37499.pedro@codesourcery.com> In-Reply-To: <201003171851.37499.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201003182214.28867.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/msg00704.txt.bz2 I see the patch went in, but how were the issues raised below addressed? I don't understand why we'd want to have a "show circular-trace-buffer" command that doesn't work correctly half the times, and hence can't be trusted. This means a frontend can not rely on "-gdb-show circular-trace-buffer" to draw a toggle button, for example (this is what I mean by calling it useless...). I find the disconnected-tracing example below quite alarming. On Wednesday 17 March 2010 18:51:37, Pedro Alves wrote: > On Wednesday 17 March 2010 18:04:52, Stan Shebs wrote: > > > - this shows that "show circular-trace-buffer" is useless. > > > - this requires users know that fact. > > > - this doesn't sound user friendly. > > > > > I'm just not seeing a problem myself - it seems obvious that circularity > > of trace buffer only matters for future tracepoint hits, and doesn't > > matter for completed trace runs, trace files, etc. But I can rephrase > > the docs to make that clearer. > > (Yes, please. Okay, let's go with that then.) > > Let me show you examples: hopefully it is easy to see with > these how "show circular-trace-buffer" is broken as is. > > > Please can we have the following inconsistencies resolved?: > > Target supports circular: > > (gdb) tar rem :9999 > (gdb) set circular-trace-buffer on > (gdb) show circular-trace-buffer > ... on. > > Fine. > > > Again, a target that supports circular, target wasn't > tracing on initial connection (disconnect-tracing off): > > > (gdb) set circular-trace-buffer on > (gdb) show circular-trace-buffer > ... on. > (gdb) tar rem :9999 > (gdb) show circular-trace-buffer > ... on. > (gdb) set disconnected-tracing on > > (gdb) tstart > (gdb) detach > > (gdb) set circular-trace-buffer off > (gdb) tar rem :9999 > (gdb) show circular-trace-buffer > ... off > > Really "off"? Ouch! See? QTstatus doesn't report the > circularity-ness, but the circularity is logically part of > the status of the current run. > > Now against a target that _doesn't_ support QTBuffer (in circular mode): > > > (gdb) set circular-trace-buffer on > (gdb) show circular-trace-buffer > ... on. > (gdb) tar rem :9999 > > (gdb) show circular-trace-buffer > Target's use of circular trace buffer is on. > > Really? > > (gdb) set circular-trace-buffer off > Target does not support this command. > (gdb) set circular-trace-buffer on > Target does not support this command. > (gdb) > > Ouch! > > You can't easily try the latter case, because a new > "set remote circular...-packet command is missing. -- Pedro Alves