This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint
- From: Pedro Alves <palves at redhat dot com>
- To: Doug Evans <xdje42 at gmail dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, gdb-patches at sourceware dot org, pmuldoon at redhat dot com, eliz at gnu dot org
- Date: Fri, 15 Nov 2013 11:37:51 +0000
- Subject: Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint
- Authentication-results: sourceware.org; auth=none
- References: <m3siv0q29h dot fsf at seba dot sebabeach dot org> <m3k3gaq3gw dot fsf at seba dot sebabeach dot org> <87bo1mwvqg dot fsf at fleche dot redhat dot com> <52853D8A dot 5070908 at redhat dot com> <CAP9bCMRMZGrBgpToFp4RzA0f9TthKy8Kg9hqL_ENX=6B0yUdzg at mail dot gmail dot 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