Re: [RFA]: Modified Watchthreads Patch

[Daniel Jacobowitz <drow@false.org>]

On Sat, Dec 11, 2004 at 07:52:08PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 11 Dec 2004 11:52:37 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Jeff Johnston <jjohnstn@redhat.com>, gdb-patches@sources.redhat.com
> > 
> > - The GDB core needs to continue to support watchpoints (hardware
> > breakpoints; et cetera) triggering in an unexpected thread.
> 
> Agreed.
> 
> > Rationale: some targets won't support any other way.  For instance
> > page protection based watchpoints on GNU/Linux would probably apply to
> > all threads.
> 
> 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 I think (and have said it several times in the past) that
> this difference in handling bp_hardware_watchpoint and
> bp_read_watchpoint/bp_access_watchpoint is a Bad Thing and we should
> rewrite it so that all the types of hardware-assisted watchpoints are
> handled in the same way.  The current code that handles
> bp_hardware_watchpoint is simply the same code that handled software
> bp_watchpoint, which to me doesn't make sense, because at least on
> x86, the hardware tells us exactly what address was written to.
> 
> (However, note that some platforms that cannot implement
> target_stopped_data_address actually take advantage of the different
> treatment of bp_hardware_watchpoint to implement `watch' even though
> `rwatch' and `awatch' are not implemented.  If we decide to make the
> treatment of all hardware-assisted watchpoints similar, we should be
> careful not to break those platforms.)

OK.  We can fix this.

> > 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?

> > or come up with a more useful behavior for software and hardware
> > watchpoints than the one I've thought of.  Can you think of one?
> 
> I think there's nothing wrong with the model you suggested, it's just
> that our handling of bp_hardware_watchpoint is wrong.  Assuming we
> change it along the lines I suggested above, do you see any further
> problems with extending watchpoints to threaded programs?

This is "extending watchpoints to specific threads" in my
understanding, not to "threaded programs" - obviously a useful feature,
but I think a different one.  Conceptually, our watchpoints already
work for threaded programs.  In practice, Jeff found that on GNU/Linux
they didn't work, and that's what he's fixing, not the "specific
threads" enhancement.  Does that make sense?

> One aspect where a kernel can help us with multi-threaded programs is
> if it tells us not only that a watchpoint has been hit, but also what
> thread hit that watchpoint.  Are there any kernel-level features that
> can be used to find that out?

Right now GDB assumes that this is reflected in inferior_ptid.  At
least for GNU/Linux, this is a reasonable assumption.  The watchpoint
is reported as an event (SIGTRAP); an event has to come from a specific
thread, and it will come from the thread which generated the
trap/fault/etc.

-- 
Daniel Jacobowitz