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

[Doug Evans <xdje42 at gmail dot com>]

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.