From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22877 invoked by alias); 21 Oct 2009 14:52:49 -0000 Received: (qmail 22856 invoked by uid 22791); 21 Oct 2009 14:52:47 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from hofr.at (HELO mail.hofr.at) (212.69.189.236) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Oct 2009 14:52:44 +0000 Received: by mail.hofr.at (Postfix, from userid 1002) id D2CB64F8B50; Wed, 21 Oct 2009 16:52:41 +0200 (CEST) Date: Wed, 21 Oct 2009 14:55:00 -0000 From: Nicholas Mc Guire To: Michael Snyder , y@opentech.at Cc: martin mangard , "gdb@sourceware.org" Subject: Re: create a watchpoint with trace functionality Message-ID: <20091021145241.GA11882@opentech.at> References: <325d766d0910210158y47944e5es48e44929fddb3770@mail.gmail.com> <4ADF1A75.7040602@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ADF1A75.7040602@vmware.com> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00334.txt.bz2 On Wed, 21 Oct 2009, Michael Snyder wrote: > martin mangard wrote: >> Hello >> >> I'm trying to trace the value of a global status variable of an >> application. This variable is changed from various code positions. I >> would like to log/trace each change of this variable without stopping >> the application (at least for a long time) in order to perform a >> longterm test. I'm currently using a hardware-watchpoint >> >> Is there a possibility to configure a "autocontinue" after a >> watchpoint-event? Which means that the changed value is printed and >> the execution continues without any user interaction (pressing "c")? > > Yes, sure. See below. > >> Is ist possible to set a tracepoint on a change of a memory area? > > A tracepoint is different from a watchpoint, and no, I don't > remember that you can do that with a tracepoint (I could be > wrong). you are right - no support for that in tracepoints - tracepoints are just like breakpoints just that they execute the bytecode provided rather than stoping the process and calling the gdb-frontend. But I guess that due to the invasive nature of watchpoints (execution timing wise) it would not make that much sense to have a that behavior in tracepoints as the prime intention of tracepoints is to allow debugging without breaking the temporal behoavior too badly (the impact is of course still significant). hofrat