This is the mail archive of the gdb-patches@sourceware.org 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: [patch] [python] Implement stop_p for gdb.Breakpoint


[apologies for the dup]

On Thu, Feb 24, 2011 at 1:03 AM, Phil Muldoon <pmuldoon@redhat.com> wrote:
> Doug Evans <dje@google.com> writes:
>
> >> I believe I have implemented all of the requests from the previous patch
> >> discussion.  I eventually renamed eval to stop_p.  Also, recently, Tom
> >> wrote a log_printf Python command that uses this feature. I've included
> >> it here, along with a few alterations Tom had to make to Breakpoint
> >> initialization to make that work.
> >>
> >> Here it is. What do you think?
> >
> > Hi.
> > Some nits and comments:
> >
> > - "consistency is good", so if we go with _p for stop_p we need to go
> > with _p for all predicates
> >   - are we prepared for that?
> >   - are there any existing predicates that don't have _p?
> >   - does python have an existing convention?
> >   [I used stop_p at the time for clarity's sake.  But I think these
> > questions need to be asked.]
>
> There are two instances that I can think of where we allow the user
> to implement methods that we supply the interface for.  One is the
> pretty-printer string, children and hint methods.  The other is the
> patch I sent last week for the redesign of parameters.  None of those
> use the _p for predicate style.  As far as I can tell (with the express
> disclaimer I am don't hack on actual Python code that much), there does
> not seem to be a convention.  I'll defer to real Python hackers
> here. For my part, I don't have much of an opinion what we call it, or
> if we should have a convention; I'll rely on the maintainers being
> directive here ;)
>

The only thing I would insist on is consistency (and documentation of it).

> [...] Anyway apologies for the confusion!
>

No worries.

> - is the logic for deciding whether to stop correct?
> >   E.g. if stop_p says "don't stop" and a condition says "stop" will
> > execution continue?  It looks like it, but maybe I'm misunderstanding
> > something.
>
> The case of the user having an old-style GDB condition, and an
> implementation of a "stop_p" is an odd one. I was inclined to disallow
> it, but eventually decided against it.  There will be conflict if stop_p
> and condition disagree.  My first thoughts are "stop" should always
> trump "don't stop". What do you think?


For things like this I like to start slow: "It's easier to relax
restrictions than it is to impose them after the fact."  If it turns out
there's a reasonable use for having both and the first release doesn't
support that, we can easily add the support later (I think!).  But if it
turns out that supporting both causes a lot of
trouble/confusion/wasted-time/whatever, and there's no real need for the
feature anyway, then removing it later will be a lot harder (if not
impossible).

So my vote would be to not support both in the first pass.
It kinda makes intuitive sense too (to me anyway).
i.e. the default implementation of "stop_p" uses the command-line condition,
and if overridden then uses the python-provided addition.
This would mean changes to the u/i, I think, in order to disallow setting a
condition if there is a python stop_p override, and possibly providing a
note in the output of info breakpoints when there is a stop_p override
(question: do these python breakpoints appear in the output of "info
breakpoints?).


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