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

[Pedro Alves <palves@redhat.com>]

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