Re: [RFA]: Modified Watchthreads Patch

[Daniel Jacobowitz <drow@false.org>]

On Sat, Dec 11, 2004 at 01:31:29PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 10 Dec 2004 18:52:37 -0500
> > From: Jeff Johnston <jjohnstn@redhat.com>
> > Cc: Daniel Jacobowitz <drow@false.org>, gdb-patches@sources.redhat.com

[A lot of stuff I completely agree with deleted.]

> > As I observed before, the actual watchpoint only needs to be set on
> > one thread and it will trigger in other threads.
> 
> One issue we should discuss is do we really want this behavior?  Do we
> really want GDB to stop the inferior when another thread hits the
> watchpoint that we set in a specific thread, or do we want a
> watchpoint to break only in the thread in which it was set?  There are
> valid arguments for both alternatives, and we never came to any
> resolution of this issue, since back when it was discussed, the state
> of support in GDB for multi-threaded programs was in flux.

Here's a proposal; I'm thinking it out as I write it, so if you can
break it you get to keep all the shiny pieces.


- The GDB core needs to continue to support watchpoints (hardware
breakpoints; et cetera) triggering in an unexpected thread.

Rationale: some targets won't support any other way.  For instance
page protection based watchpoints on GNU/Linux would probably apply to
all threads.

- As an optimization, the interfaces for inserting and removing
watchpoints could specify a thread to apply the watchpoint to.
The target could, if it supports this operation, apply the watchpoint
to only that thread.

How useful would this be?  For hardware read or write watchpoints,
very.  For "normal" hardware watchpoints (bp_hardware_watchpoint), I
think almost not at all.  GDB relies on knowing the value of all
watched locations to decide whether the watchpoint "triggered" and
should stop the program, right?  If other threads modify the watched
location, GDB would report the watchpoint the next time we stop,
because the value would appear to change.  And consider a scenario like
this:

  Thread A		Thread B

    *p = 0
			 *p = 1
    *p = 0
			 *p = 1
    *p = 0
			 *p = 1
    *p = 0

Assuming that the program didn't stop for any other reason, and that
hardware watchpoints trigger after the write is executed, "watch *p
thread A" would never trigger, because the value would always appear to
be the same.  This fails my usual spot-check for a useful user
interface design, because it is difficult to explain or justify it
without resorting to an explanation of the implementation's
limitations.

If we want thread-specific watchpoint insertion, I think that we need
to either restrict it to rwatch/awatch, 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?

-- 
Daniel Jacobowitz