This is the mail archive of the 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, doc RFA] Allow CLI and Python conditions to be set on same breakpoint

On Fri, Nov 15, 2013 at 3:37 AM, Pedro Alves <> wrote:
> On 11/15/2013 05:34 AM, Doug Evans wrote:
>> On Thu, Nov 14, 2013 at 1:15 PM, Pedro Alves <> 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
>  (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.

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