Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@vmware.com>
To: Nicholas Mc Guire <hofrat@opentech.at>
Cc: "y@opentech.at" <y@opentech.at>,
	martin mangard <martin@mangard.at>,
	  "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: create a watchpoint with trace functionality
Date: Sun, 25 Oct 2009 12:57:00 -0000	[thread overview]
Message-ID: <4AE3AFB5.8050809@vmware.com> (raw)
In-Reply-To: <20091021145241.GA11882@opentech.at>

Nicholas Mc Guire wrote:
> 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).

Hardware watchpoints associated with tracepoints would make sense.
Software watchpoints wouldn't.

And of course, there are resource limits associated with hardware
watchpoints.


      reply	other threads:[~2009-10-25  2:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-21 13:37 martin mangard
2009-10-21 14:35 ` Michael Snyder
2009-10-21 14:55   ` Nicholas Mc Guire
2009-10-25 12:57     ` Michael Snyder [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AE3AFB5.8050809@vmware.com \
    --to=msnyder@vmware.com \
    --cc=gdb@sourceware.org \
    --cc=hofrat@opentech.at \
    --cc=martin@mangard.at \
    --cc=y@opentech.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox