Re: [mi] watchpoint-scope exec async command

[Bob Rossi <bob at brasko dot net>]

On Tue, Mar 29, 2005 at 11:29:48PM +0200, Eli Zaretskii wrote:
> [Sorry for a late response: I needed to refresh my memory of how the
> related code works.]

Are you serious? That was like the speed of light compared to what I'm
used to.
> Let's not forget that software watchpoints also share some (most?) of
> the code used for hardware data-write watchpoints.  I'm quite sure
> that the scope breakpoint was invented for software watchpoints,
> because hardware watchpoints simply don't need it: they incur no
> overhead if they are not deleted, as long as they are not hit; and
> once they are hit and we find them to be out of scope, we do TRT: mark
> both the watchpoint and its related breakpoint for deletion at next
> stop.  (I suspect that we don't delete them right away due to some
> peculiarity of software watchpoints that are implemented by
> single-stepping the inferior.)
> 
> Bob, could you also try the same program with a software watchpoint,
> and see if you hit the same bug or not?  If the behavior is different,
> please show where the GDB execution thread goes a different way and
> how it avoids the crash.  (Forcing software watchpoints might not be
> easy.  One way, on a x86 machine, is to watch a region that is more
> than 16 bytes long.  Another way is to build a hacked version of GDB
> that uses only software watchpoints.)

It'll be a little bit before I can figure out how to present all the
information that you need. However, in case it clear's things up for
you, here's some more information. (this info makes me even *more*
confused.)

When running with software breakpoints, the crash does not happen, and
valgrind is happy. Now, what confuses me is that the memory for the
related_breakpoint is still deleted in delete_breakpoint and when we 
set the disposition of the deleted "related_breakpoint" at 
breakpoint.c:1022(insert_bp_location), things seem to work OK.

I don't understand this, but i will present you with the information you
asked for as soon as possible.

Bob Rossi