[commit] breakpoint.c (breakpoint_cond_eval): Fix and enhance comment.

[commit] breakpoint.c (breakpoint_cond_eval): Fix and enhance comment.

[Doug Evans]

Hi.

fyi, I committed this.
It took a bit to determine why breakpoint_cond_eval returns
the inverted condition result, so I wrote it down.

2013-11-13  Doug Evans  <xdje42@gmail.com>

	* breakpoint.c (breakpoint_cond_eval): Fix and enhance comment.

diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index 36252ee..f0b496d 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -4649,10 +4649,12 @@ bpstat_print (bpstat bs, int kind)
   return PRINT_UNKNOWN;
 }
 
-/* Evaluate the expression EXP and return 1 if value is zero.  This is
-   used inside a catch_errors to evaluate the breakpoint condition.
+/* Evaluate the expression EXP and return 1 if value is zero.
+   This returns the inverse of the condition because it is called
+   from catch_errors which returns 0 if an exception happened, and if an
+   exception happens we want execution to stop.
    The argument is a "struct expression *" that has been cast to a
-   "char *" to make it pass through catch_errors.  */
+   "void *" to make it pass through catch_errors.  */
 
 static int
 breakpoint_cond_eval (void *exp)

[PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint

[Doug Evans]

Hi.

Way back when this was added I wanted to prevent both CLI and Python
conditions from being set on the same breakpoint because it wasn't
clear there wouldn't be any problems allowing both.
[And it's easier to relax restrictions than to impose them after the fact.]

Enough time has passed and I can't think of a reason to keep the
current restriction.

This patch removes the restriction.
I couldn't find a doc change that's necessary.
I added something to the Python section to say setting both is OK.

Regression tested on amd64-linux.

Ok to check in?

2013-11-14  Doug Evans  <xdje42@gmail.com>

	* breakpoint.c (condition_command): Allow CLI condition and Python
	condition to be set on same breakpoint.
	(bpstat_check_breakpoint_conditions): Handle both CLI and Python
	conditions being present.
	* python/py-breakpoint.c (local_setattro): Delete.
	(breakpoint_object_type): Update.

	doc/
	* gdb.texinfo (Breakpoints In Python): Mention that a CLI condition
	and Python condition are allowed on the same breakpoint.

	testsuite/
	* gdb.python/py-breakpoint.c: Verify able to set CLI condition and
	Python condition on same breakpoint.

diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index 5bfed9d..4baac57 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -1048,14 +1048,6 @@ condition_command (char *arg, int from_tty)
   ALL_BREAKPOINTS (b)
     if (b->number == bnum)
       {
-	/* Check if this breakpoint has a Python object assigned to
-	   it, and if it has a definition of the "stop"
-	   method.  This method and conditions entered into GDB from
-	   the CLI are mutually exclusive.  */
-	if (b->py_bp_object
-	    && gdbpy_breakpoint_has_py_cond (b->py_bp_object))
-	  error (_("Cannot set a condition where a Python 'stop' "
-		   "method has been defined in the breakpoint."));
 	set_breakpoint_condition (b, p, from_tty);
 
 	if (is_breakpoint (b))
@@ -5112,8 +5104,12 @@ bpstat_check_breakpoint_conditions (bpstat bs, ptid_t ptid)
   int thread_id = pid_to_thread_id (ptid);
   const struct bp_location *bl;
   struct breakpoint *b;
-  int value_is_zero = 0;
-  struct expression *cond;
+  struct expression *cli_cond;
+  /* Non-zero if there's a CLI condition *and* it evaluates to true.  */
+  int cli_cond_is_true = 0;
+  int have_py_cond = 0;
+  /* Non-zero if there's a Python condition *and* it evaluates to true.  */
+  int py_cond_is_true = 0;
 
   gdb_assert (bs->stop);
 
@@ -5142,20 +5138,33 @@ bpstat_check_breakpoint_conditions (bpstat bs, ptid_t ptid)
       return;
     }
 
+  /* The default is to stop when the breakpoint is reached.
+     However, if the breakpoint has any condition (either from the CLI, or
+     from Python, or both), then only stop if at least one of the conditions
+     is TRUE.  */
+
   /* Evaluate Python breakpoints that have a "stop" method implemented.  */
   if (b->py_bp_object)
-    bs->stop = gdbpy_should_stop (b->py_bp_object);
+    {
+      /* We have to call this even if there is no "stop" method in order
+	 to call the FinishBreakpoint pre,post stop hooks.  */
+      int py_should_stop = gdbpy_should_stop (b->py_bp_object);
+
+      have_py_cond = gdbpy_breakpoint_has_py_cond (b->py_bp_object);
+      if (have_py_cond)
+	py_cond_is_true = py_should_stop;
+    }
 
   if (is_watchpoint (b))
     {
       struct watchpoint *w = (struct watchpoint *) b;
 
-      cond = w->cond_exp;
+      cli_cond = w->cond_exp;
     }
   else
-    cond = bl->cond;
+    cli_cond = bl->cond;
 
-  if (cond && b->disposition != disp_del_at_next_stop)
+  if (cli_cond && b->disposition != disp_del_at_next_stop)
     {
       int within_current_scope = 1;
       struct watchpoint * w;
@@ -5205,25 +5214,35 @@ bpstat_check_breakpoint_conditions (bpstat bs, ptid_t ptid)
 	    within_current_scope = 0;
 	}
       if (within_current_scope)
-	value_is_zero
-	  = catch_errors (breakpoint_cond_eval, cond,
+	{
+	  int cond_result =
+	    catch_errors (breakpoint_cond_eval, cli_cond,
 			  "Error in testing breakpoint condition:\n",
 			  RETURN_MASK_ALL);
+
+	  /* See breakpoint_cond_eval for why it returns the inverted CLI
+	     condition.  */
+	  cli_cond_is_true = !cond_result;
+	}
       else
 	{
 	  warning (_("Watchpoint condition cannot be tested "
 		     "in the current scope"));
 	  /* If we failed to set the right context for this
 	     watchpoint, unconditionally report it.  */
-	  value_is_zero = 0;
+	  cli_cond_is_true = 1;
 	}
       /* FIXME-someday, should give breakpoint #.  */
       value_free_to_mark (mark);
     }
 
-  if (cond && value_is_zero)
+  /* Stop if any condition says so.  */
+  if (cli_cond || have_py_cond)
     {
-      bs->stop = 0;
+      /* bs->stop is already set, so we only have to handle the negative
+	 result: Only continue if all conditions are false.  */
+      if (!cli_cond_is_true && !py_cond_is_true)
+	bs->stop = 0;
     }
   else if (b->ignore_count > 0)
     {
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 84acd5c..c872960 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -27196,6 +27196,12 @@ methods have a chance to execute at that location.  In this scenario
 if one of the methods returns @code{True} but the others return
 @code{False}, the inferior will still be stopped.
 
+A breakpoint may have both a normal breakpoint condition
+(@pxref{Conditions, ,Break Conditions}) and a Python
+@code{gdb.Breakpoint.stop} condition.
+Both will be evaluated and if either return @code{True} then the
+inferior will be stopped, otherwise the inferior will continue.
+
 You should not alter the execution state of the inferior (i.e.@:, step,
 next, etc.), alter the current frame context (i.e.@:, change the current
 active frame), or alter, add or delete any breakpoint.  As a general
diff --git a/gdb/python/py-breakpoint.c b/gdb/python/py-breakpoint.c
index e83471e..6bc96e2 100644
--- a/gdb/python/py-breakpoint.c
+++ b/gdb/python/py-breakpoint.c
@@ -933,37 +933,6 @@ gdbpy_initialize_breakpoints (void)
 
 \f
 
-/* Helper function that overrides this Python object's
-   PyObject_GenericSetAttr to allow extra validation of the attribute
-   being set.  */
-
-static int 
-local_setattro (PyObject *self, PyObject *name, PyObject *v)
-{
-  breakpoint_object *obj = (breakpoint_object *) self;  
-  char *attr = python_string_to_host_string (name);
-  
-  if (attr == NULL)
-    return -1;
-  
-  /* If the attribute trying to be set is the "stop" method,
-     but we already have a condition set in the CLI, disallow this
-     operation.  */
-  if (strcmp (attr, stop_func) == 0 && obj->bp->cond_string)
-    {
-      xfree (attr);
-      PyErr_SetString (PyExc_RuntimeError, 
-		       _("Cannot set 'stop' method.  There is an " \
-			 "existing GDB condition attached to the " \
-			 "breakpoint."));
-      return -1;
-    }
-  
-  xfree (attr);
-  
-  return PyObject_GenericSetAttr ((PyObject *)self, name, v);  
-}
-
 static PyGetSetDef breakpoint_object_getset[] = {
   { "enabled", bppy_get_enabled, bppy_set_enabled,
     "Boolean telling whether the breakpoint is enabled.", NULL },
@@ -1034,7 +1003,7 @@ PyTypeObject breakpoint_object_type =
   0,				  /*tp_call*/
   0,				  /*tp_str*/
   0,				  /*tp_getattro*/
-  (setattrofunc)local_setattro,   /*tp_setattro */
+  0,				  /*tp_setattro */
   0,				  /*tp_as_buffer*/
   Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE,  /*tp_flags*/
   "GDB breakpoint object",	  /* tp_doc */
diff --git a/gdb/testsuite/gdb.python/py-breakpoint.exp b/gdb/testsuite/gdb.python/py-breakpoint.exp
index e2a169b..03c4f92 100644
--- a/gdb/testsuite/gdb.python/py-breakpoint.exp
+++ b/gdb/testsuite/gdb.python/py-breakpoint.exp
@@ -257,25 +257,39 @@ gdb_test "python print (also_eval_bp1.count)" "4" \
 gdb_test "python print (eval_bp1.count)" "4" \
     "Check non firing same-location breakpoint eval function was also called at each stop."
 
+# Test mixed CLI/Python breakpoint conditions.
+
 delete_breakpoints
 set cond_bp [gdb_get_line_number "Break at multiply."]
 gdb_py_test_silent_cmd  "python eval_bp1 = bp_eval(\"$cond_bp\")" "Set breakpoint" 0
 set test_cond {cond $bpnum}
-gdb_test "$test_cond \"foo==3\"" "Cannot set a condition where a Python.*" \
-    "Check you cannot add a CLI condition to a Python breakpoint that" \
+gdb_test_no_output "$test_cond \"foo==3\"" \
+    "Check you can add a CLI condition to a Python breakpoint that" \
     "has defined stop"
+
+if ![runto_main] then {
+    fail "Cannot run to main."
+    return 0
+}
+delete_breakpoints
 gdb_py_test_silent_cmd  "python eval_bp2 = basic(\"$cond_bp\")" "Set breakpoint" 0
-gdb_py_test_silent_cmd  "python eval_bp2.condition = \"1==1\"" "Set a condition" 0
+gdb_py_test_silent_cmd  "python eval_bp2.condition = \"i==3\"" "Set a condition" 0
 gdb_py_test_multiple "Construct an eval function" \
   "python" "" \
   "def stop_func ():" "" \
-  "   return True" "" \
+  "   return gdb.parse_and_eval(\"i\") == 1" "" \
   "end" ""
+gdb_py_test_silent_cmd "python eval_bp2.stop = stop_func" \
+    "Assign stop function to a breakpoint that has a condition" 1
+gdb_continue_to_breakpoint "Break at multiply." ".*/$srcfile:$bp_location2.*"
+gdb_test "print i" "1" "Check python condition triggered"
+gdb_continue_to_breakpoint "Break at multiply." ".*/$srcfile:$bp_location2.*"
+gdb_test "print i" "3" "Check cli condition triggered"
 
-gdb_test "python eval_bp2.stop = stop_func"  \
-    "RuntimeError: Cannot set 'stop' method.*" \
-    "Assign stop function to a breakpoint that has a condition"
-
+if ![runto_main] then {
+    fail "Cannot run to main."
+    return 0
+}
 delete_breakpoints
 gdb_breakpoint [gdb_get_line_number "Break at multiply."]
 gdb_py_test_silent_cmd  "python check_eval = bp_eval(\"$bp_location2\")" "Set breakpoint" 0

Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint

[Pedro Alves]

On 11/14/2013 05:48 PM, Doug Evans wrote:

> Regression tested on amd64-linux.
> 
> Ok to check in?
> 

This is fine with me.

> -  if (cond && b->disposition != disp_del_at_next_stop)
> +  if (cli_cond && b->disposition != disp_del_at_next_stop)

(BTW, I notice that the 'b->disposition != disp_del_at_next_stop'
handling in this function looks suspicious.)

>        if (within_current_scope)
> -	value_is_zero
> -	  = catch_errors (breakpoint_cond_eval, cond,
> +	{
> +	  int cond_result =

= goes on the next line.

-- 
Pedro Alves

Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint

[Phil Muldoon]

On 14/11/13 17:48, Doug Evans wrote:
> Hi.
> 
> Way back when this was added I wanted to prevent both CLI and Python
> conditions from being set on the same breakpoint because it wasn't
> clear there wouldn't be any problems allowing both.
> [And it's easier to relax restrictions than to impose them after the fact.]

No objections from me. I have not looked at the patch in the context
of breakpoint.c, but as long as all "stop" callbacks have a chance to
run regardless of whether a previous "stop" or cli condition has had a
chance to execute it is fine.  Looking at the patch, it seems it did
not alter this loop, so this is still the case, is that right?

Cheers,

Phil

 

Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint

[Tom Tromey]

>>>>> "Doug" == Doug Evans <xdje42@gmail.com> writes:

Doug> +A breakpoint may have both a normal breakpoint condition
Doug> +(@pxref{Conditions, ,Break Conditions}) and a Python
Doug> +@code{gdb.Breakpoint.stop} condition.
Doug> +Both will be evaluated and if either return @code{True} then the
Doug> +inferior will be stopped, otherwise the inferior will continue.

I'm not certain that these are the best semantics.

A motivating case for the Python "stop" method was to be able to let
Python authors write new kinds of breakpoints.

Say, for example, one wanted a breakpoint that triggered based on a
Python source file and line.  One could implement this by putting a
breakpoint in the Python interpreter with a suitable "stop" method.

In order for this to make sense, all the non-matching calls in the
interpreter must be discarded.  That is, stop returns false.

In this scenario, your proposed patch would go on to evaluate the
condition and perhaps break anyway.  But this violates the whole idea of
the new breakpoint.  Here, the CLI condition would most usefully be an
additional condition -- not a parallel one.


This particular example would be better with some other additions to the
gdb breakpoint API; and maybe those would obviate the need for this dual
purposing.  But since we don't have those additions, it remains unclear
to me that "|" is better than "&&" here.

Tom

Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint

[Pedro Alves]

On 11/14/2013 08:53 PM, Tom Tromey wrote:
>>>>>> "Doug" == Doug Evans <xdje42@gmail.com> writes:
> 
> Doug> +A breakpoint may have both a normal breakpoint condition
> Doug> +(@pxref{Conditions, ,Break Conditions}) and a Python
> Doug> +@code{gdb.Breakpoint.stop} condition.
> Doug> +Both will be evaluated and if either return @code{True} then the
> Doug> +inferior will be stopped, otherwise the inferior will continue.
> 
> I'm not certain that these are the best semantics.
> 
> A motivating case for the Python "stop" method was to be able to let
> Python authors write new kinds of breakpoints.
> 
> Say, for example, one wanted a breakpoint that triggered based on a
> Python source file and line.  One could implement this by putting a
> breakpoint in the Python interpreter with a suitable "stop" method.
> 
> In order for this to make sense, all the non-matching calls in the
> interpreter must be discarded.  That is, stop returns false.
>
> In this scenario, your proposed patch would go on to evaluate the
> condition and perhaps break anyway.  
> But this violates the whole idea of
> the new breakpoint.  Here, the CLI condition would most usefully be an
> additional condition -- not a parallel one.

That does make sense.  In that scenario, it then sounds like it's
best to think of the "stop" method more like a ops->check_status
implementation/extension, than a breakpoint condition.

> This particular example would be better with some other additions to the
> gdb breakpoint API; and maybe those would obviate the need for this dual
> purposing.  But since we don't have those additions, it remains unclear
> to me that "|" is better than "&&" here.

Yeah, it does sound like && is more useful.  To get "|", the user can
set another breakpoint at the same address/whatever with a cli condition.

-- 
Pedro Alves

Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint

[Doug Evans]

On Thu, Nov 14, 2013 at 1:15 PM, Pedro Alves <palves@redhat.com> wrote:
> On 11/14/2013 08:53 PM, Tom Tromey wrote:
>>>>>>> "Doug" == Doug Evans <xdje42@gmail.com> writes:
>>
>> Doug> +A breakpoint may have both a normal breakpoint condition
>> Doug> +(@pxref{Conditions, ,Break Conditions}) and a Python
>> Doug> +@code{gdb.Breakpoint.stop} condition.
>> Doug> +Both will be evaluated and if either return @code{True} then the
>> Doug> +inferior will be stopped, otherwise the inferior will continue.
>>
>> I'm not certain that these are the best semantics.
>>
>> A motivating case for the Python "stop" method was to be able to let
>> Python authors write new kinds of breakpoints.
>>
>> Say, for example, one wanted a breakpoint that triggered based on a
>> Python source file and line.  One could implement this by putting a
>> breakpoint in the Python interpreter with a suitable "stop" method.
>>
>> In order for this to make sense, all the non-matching calls in the
>> interpreter must be discarded.  That is, stop returns false.
>>
>> In this scenario, your proposed patch would go on to evaluate the
>> condition and perhaps break anyway.
>> But this violates the whole idea of
>> the new breakpoint.  Here, the CLI condition would most usefully be an
>> additional condition -- not a parallel one.
>
> That does make sense.  In that scenario, it then sounds like it's
> best to think of the "stop" method more like a ops->check_status
> implementation/extension, than a breakpoint condition.

Need More Data.
In this scenario, when would one typically add a CLI condition to such
a Python interpreter breakpoint?

Plus if this is really a check_status thing then I wonder if
gdb.Breakpoint is going down the wrong path and we should be providing
a class where users can override breakpoint_ops.

>> This particular example would be better with some other additions to the
>> gdb breakpoint API; and maybe those would obviate the need for this dual
>> purposing.  But since we don't have those additions, it remains unclear
>> to me that "|" is better than "&&" here.
>
> Yeah, it does sound like && is more useful.  To get "|", the user can
> set another breakpoint at the same address/whatever with a cli condition.

That's a good point.

Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint

[Pedro Alves]

On 11/15/2013 05:34 AM, Doug Evans wrote:
> On Thu, Nov 14, 2013 at 1:15 PM, Pedro Alves <palves@redhat.com> wrote:

>> That does make sense.  In that scenario, it then sounds like it's
>> best to think of the "stop" method more like a ops->check_status
>> implementation/extension, than a breakpoint condition.
> 
> Need More Data.
> In this scenario, when would one typically add a CLI condition to such
> a Python interpreter breakpoint?

Not exactly sure what you're asking, but say, you're debugging a C program
that uses Python as extension language, like e.g., GDB, and you have
something buggy in the extension support, only triggered on a particular
path of this Python script, but of all the 2000000 calls to the
script, you can tell that only those for a certain condition in
the C side of the program not exposed to Python would be interesting, as
they're the ones that seem to trigger the bug.  You'd use the fictitious
"python-interp-breakpoint" command to set a breakpoint in the Python
script, and do:

 (gdb) python-interp-breakpoint some-other-cool-extention.py:30
 (gdb) condition $bpnum global_in_the_C_code_of_the_program==0xf00

That is, please ignore all hits of the python breakpoint unless
this particular condition in my program is true.


I imagine that such a thing would be useful for debugging the
Python interpreter itself too.


> Plus if this is really a check_status thing then I wonder if
> gdb.Breakpoint is going down the wrong path and we should be providing
> a class where users can override breakpoint_ops.

Yeah, I meant it only in the abstract.  My view is that breakpoint_ops
is messy at places, and exposing it in full directly at least in its
current state would be a bad idea.

>>> This particular example would be better with some other additions to the
>>> gdb breakpoint API; and maybe those would obviate the need for this dual
>>> purposing.  But since we don't have those additions, it remains unclear
>>> to me that "|" is better than "&&" here.
>>
>> Yeah, it does sound like && is more useful.  To get "|", the user can
>> set another breakpoint at the same address/whatever with a cli condition.
> 
> That's a good point.

-- 
Pedro Alves

Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint

[Doug Evans]

On Fri, Nov 15, 2013 at 3:37 AM, Pedro Alves <palves@redhat.com> wrote:
> On 11/15/2013 05:34 AM, Doug Evans wrote:
>> On Thu, Nov 14, 2013 at 1:15 PM, Pedro Alves <palves@redhat.com> wrote:
>
>>> That does make sense.  In that scenario, it then sounds like it's
>>> best to think of the "stop" method more like a ops->check_status
>>> implementation/extension, than a breakpoint condition.
>>
>> Need More Data.
>> In this scenario, when would one typically add a CLI condition to such
>> a Python interpreter breakpoint?
>
> Not exactly sure what you're asking, but say, you're debugging a C program
> that uses Python as extension language, like e.g., GDB, and you have
> something buggy in the extension support, only triggered on a particular
> path of this Python script, but of all the 2000000 calls to the
> script, you can tell that only those for a certain condition in
> the C side of the program not exposed to Python would be interesting, as
> they're the ones that seem to trigger the bug.  You'd use the fictitious
> "python-interp-breakpoint" command to set a breakpoint in the Python
> script, and do:
>
>  (gdb) python-interp-breakpoint some-other-cool-extention.py:30
>  (gdb) condition $bpnum global_in_the_C_code_of_the_program==0xf00
>
> That is, please ignore all hits of the python breakpoint unless
> this particular condition in my program is true.

That's really just the "It's more useful to combine them as &&" view
(which I agree is a good point).
Same thing can apply to other functionality implemented as a Python
breakpoint with "stop".
I can think of a couple of other ways to achieve it, but && makes it easy.

Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint

[Pedro Alves]

On 11/15/2013 03:54 PM, Doug Evans wrote:

> That's really just the "It's more useful to combine them as &&" view
> (which I agree is a good point).

I'm afraid I'm confused.  Were you asking for something else?  I can't
really understand whether it was something like that you were asking for,
or something else, whatever it would be.  I feel something is getting
lost in translation, sorry about that.  :-(

> Same thing can apply to other functionality implemented as a Python
> breakpoint with "stop".

WDYM?  This sentence really confuses me.  :-(  What "thing"?

> I can think of a couple of other ways to achieve it, but && makes it easy.

-- 
Pedro Alves

Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint

[Doug Evans]

On Fri, Nov 15, 2013 at 8:38 AM, Pedro Alves <palves@redhat.com> wrote:
> On 11/15/2013 03:54 PM, Doug Evans wrote:
>
>> That's really just the "It's more useful to combine them as &&" view
>> (which I agree is a good point).
>
> I'm afraid I'm confused.  Were you asking for something else?  I can't
> really understand whether it was something like that you were asking for,
> or something else, whatever it would be.  I feel something is getting
> lost in translation, sorry about that.  :-(

No worries.

>> Same thing can apply to other functionality implemented as a Python
>> breakpoint with "stop".
>
> WDYM?  This sentence really confuses me.  :-(  What "thing"?
>
>> I can think of a couple of other ways to achieve it, but && makes it easy.

I just meant I can imagine adding a cli condition to other
python-conditioned breakpoints.

Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint

[Tom Tromey]

>>>>> "Doug" == Doug Evans <xdje42@gmail.com> writes:

Doug> Need More Data.

That goes both ways.

If you still prefer the other semantics, perhaps you could explain why.

Doug> In this scenario, when would one typically add a CLI condition to such
Doug> a Python interpreter breakpoint?

It's a flaw in this example.  But the example is just an example.  I
would hope it does not need to be bulletproof in order to persuade one
that perhaps the proposed semantics are not obviously ideal.

Doug> Plus if this is really a check_status thing then I wonder if
Doug> gdb.Breakpoint is going down the wrong path and we should be providing
Doug> a class where users can override breakpoint_ops.

Yes.  However that ran aground of difficulties when attempted.  The main
issue, I think -- and this goes back to the ABI business -- is that
breakpoint_ops are a bit weird; and breakpoint.c is clearly in need of
some refactoring and more replacement of bptype checks with method
calls.

I'd be delighted if somebody did this.  It hasn't made the top of our
list yet.

Tom

Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint

[Doug Evans]

On Fri, Nov 15, 2013 at 11:15 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Doug" == Doug Evans <xdje42@gmail.com> writes:
>
> Doug> Need More Data.
>
> That goes both ways.
>
> If you still prefer the other semantics, perhaps you could explain why.

I don't prefer the other semantics.
Composing || with separate breakpoints is easy enough, and it's harder
to compose && (*1).
"works for me"

I was considering && early on, but got off track.  Oh well.

---
(*1): The rest of the discussion seemed to be trying to imply there
was something more than this simple sentence involved in the
explanation, and I was trying to understand what.