This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA]: Modified Watchthreads Patch


> Date: Sat, 11 Dec 2004 13:02:36 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: jjohnstn@redhat.com, gdb-patches@sources.redhat.com
> 
> > Another, even better (IMHO) rationale: one important reason for using
> > watchpoints is to find what code accesses some specific data; when we
> > use watchpoints for this, we more often than not do not know what
> > thread will access the data.
> 
> That's just a watchpoint without an explicit thread specified.  That's
> the default when you say "watch foo".

Yes, but what is the difference between unexpected thread and any
thread?  In practice, it means you will need to stop on any thread,
right?

> > > Assuming that the program didn't stop for any other reason, and that
> > > hardware watchpoints trigger after the write is executed
> > 
> > (I note in parens that on x86, watchpoints trigger _before_ the write
> > is executed.  Not sure if it matters here.)
> 
> How do we get the "new value" for a watchpoint, then?  Do we step over
> the instruction?

Oops, sorry, I managed to completely confuse myself.  You are right,
watchpoints trigger after the data has been written.

> This is "extending watchpoints to specific threads" in my
> understanding, not to "threaded programs"

Okay, I agree.  But whetever the name, I think such an extension
should be a useful one.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]