Re: [WIP] pending breakpoint support

[Thomas Fitzsimmons <fitzsim@redhat.com>]

On Wed, 2003-11-26 at 15:30, Michael Snyder wrote:
> J. Johnston wrote:
> > Thomas Fitzsimmons wrote:
> > 
> >> On Fri, 21 Nov 2003 17:46:43 -0500, J. Johnston wrote:
> >>
> >>
> >>> I have appended a patch to replace the previous hack.  I changed the
> >>> code so it supports conditionals and doesn't fail if you specify
> >>> source:line breakpoints. I also changed the mechanism to add a new flag
> >>> to the breakpoint struct called "pending".  As you will notice, this
> >>> adds a large number of checks because you can't just check for
> >>> enable_state == bp_enabled without also checking for the pending 
> >>> flag. I think that having two more enable states would have been 
> >>> simpler, but
> >>> I will let all of you decide.  With this change, you can enable/disable
> >>> the pending breakpoint and see any conditionals attached to it. Commands
> >>> should also work.
> >>>
> >>
> >>
> >> I've been using this patch since it was posted and it is very useful for
> >> both Mozilla and libgcj debugging.  One minor UI nit: I don't think I
> >> should be asked whether to make a breakpoint pending; I think the
> >> "pending" message is enough (or maybe the behaviour could be
> >> configurable).
> >>
> > 
> > IMO, the query should be the default.  If there is no query, every time 
> > you make a mistake, you would end up with an unwanted pending 
> > breakpoint.  Anybody, feel free to jump in with your comments.
> 
> That's right.  That's why at NeXT we had to keep some distinction
> between a pending breakpoint and an ordinary breakpoint.  Otherwise,
> you mistype "break mian", and you never find out you've made a mistake
> until it's too late.
> 

The differences in the pending and non-pending output messages should be
enough to indicate that something's wrong:

Breakpoint 1 (mian) pending.

vs.

Breakpoint 1 at 0x806b513: file main.c, line 180.

Anyway, it's not a big deal.

> > Regarding the annoyance of having to answer many queries, this could be 
> > addressed in the future with a new setting, but that should be kept 
> > separate from the initial base implementation.
> 
> Maybe a "-f" (for force) option.  "Break here, and I really mean it".
> 

Hmm, I think I would prefer a setting.  But like Jeff said, that feature
can be added later if it's generally desired.

Tom