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


Tom> My reason is that the Python method is an implementation detail of some
Tom> kind of "stop point" provided by a Python script. ÂIt is not readily
Tom> mutable by the user. ÂOn the other hand, the condition is something
Tom> explicitly under the user's control.

Doug> That sounds a bit weird.
Doug> The python method is part of an API.
Doug> APIs are not implementation details.

I think we are using the same words to mean different things.

I was using this from the point of view of writing a gdb extension using
the new feature.  E.g., consider the log-printf code.  The new method is
used by log-printf to do its work.  Here, the method is an
implementation detail of log-printf.

I'm sorry for being unclear.

Tom> I think the most conservative approach is to make it an error for the
Tom> user to set a condition on a breakpoint that has a stop_p method, and
Tom> vice versa. ÂThat preserves the ability to make a different decision
Tom> later.

Doug> That's what I'd do.  I don't see the contradiction.
Doug> [Remember I'm talking about an *intuitive* sense here, not any literal
Doug> sense ("literal" as in something I might intend we document).
Doug> If my intuitive sense doesn't work for you, you don't have to use it.
Doug> :-)  We seem to both agree on the end result.]

I don't really agree, but I think it is less important than getting some
variant of the patch in.

Phil is already implementing this and I think should have a new patch
shortly.

Tom


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