This is the mail archive of the gdb@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: [mi] watchpoint-scope exec async command


> Date: Wed, 30 Mar 2005 21:33:07 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: GDB <gdb@sources.redhat.com>
> 
> No, we're crashing earlier than that.  This was in one of Bob's earlier
> messages; we crash here:
> 
>    1021           if (bpt->owner->related_breakpoint)
>    1022             bpt->owner->related_breakpoint->disposition = disp_del_at_next_stop;
>    1023           bpt->owner->disposition = disp_del_at_next_stop;

Right.

> > If we don't arrange a scope breakpoint for a hardware watchpoint, we
> > won't hit the problem Bob reported.
> 
> I think this would be pretty tricky.  We would have to recognize that
> if the next thing to trigger is the watchpoint, it doesn't "count".

Sorry, I'm not following.  What I meant was this: when we _create_ the
watchpoint, if it's a hardware-assisted watchpoint, we should simply
not arrange a scope breakpoint for it.  How is that tricky, and why
would we need to know that the next thing to trigger is the
watchpoint?

> The second seems marginally cleaner to me.

I wouldn't mind the second alternative too much.

> Even better would be deleting the software watchpoint at the same
> time

How is this different from what I said?  I said:

> The second alternative is to treat scope breakpoints specially in
> breakpoint_auto_delete: when we see a scope breakpoint that is marked
> for deletion, we will have to find its watchpoint, and if that
> watchpoint is a hardware watchpoint, we will have to delete that
> watchpoint as well.


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