This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [WIP] pending breakpoint support
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