From: Phil Muldoon <pmuldoon@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: Doug Evans <dje@google.com>, gdb-patches@sourceware.org
Subject: Re: [patch] Add an evaluation function hook to Python breakpoints.
Date: Tue, 14 Dec 2010 19:51:00 -0000 [thread overview]
Message-ID: <m3mxo8uo9g.fsf@redhat.com> (raw)
In-Reply-To: <m34oags1q1.fsf@fleche.redhat.com> (Tom Tromey's message of "Tue, 14 Dec 2010 10:28:38 -0700")
Tom Tromey <tromey@redhat.com> writes:
>>>>>> "Doug" == Doug Evans <dje@google.com> writes:
>
> Doug> And the name "evaluate" doesn't feel right either.
>
> I agree.
It's no problem to allow the implemented function to be called
"condition" or anything else.
> Doug> OTOH, it seems like Python-based breakpoints have two conditions
> Doug> now (or at least two kinds of conditions one has to think about).
> Doug> One set with the "condition" command and one from the "evaluate"
> Doug> API function. IWBN to have only one, at least conceptually.
> Doug> Maybe you could rename "evaluate" to "condition" (or some such, I
> Doug> realize there's already a "condition"), and have the default be to
> Doug> use the CLI condition.
>
> This would be fine with me as long as it meets all the goals above.
So let me be sure I understand correctly:
class MyBreakpoint (gdb.Breakpoint):
def condition (self):
inf_val = gdb.parse_and_eval("i")
if inf_val == 3:
return True
return False
foo = MyBreakpoint ("myfile.c:42")
Would be how we work with the new Python evaluation breakpoints.
And
bar = gdb.Breakpoint("myfile.c:42)
bar.condition = "i == 2"
Would be the old style. In this case "foo" would have had the "condition"
method executed three times (up until i == 2), always returning "False"
(IE, don't stop) before the "bar" condition of the other breakpoint
stopped the inferior with its condition.
In the case of a new style breakpoint having both a CLI .condition() AND
an implemented method (though I could never see why you would want to do
this), whichever of those methods told GDB not to stop would trump the
other. (GDB assumes in bpstat_stop_status that the breakpoint will stop
the inferior (other than special cases like moribund breakpoints) and it
is up to the breakpoint evaluation to say, "hey don't stop". So the
stop-bit is never set by the conditional stuff, just unset).
How does this sound?
Cheers
Phil
next prev parent reply other threads:[~2010-12-14 19:51 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-13 13:50 Phil Muldoon
2010-12-13 14:19 ` Eli Zaretskii
2010-12-13 14:47 ` Phil Muldoon
2010-12-13 15:07 ` Eli Zaretskii
2010-12-13 17:21 ` Phil Muldoon
2010-12-13 17:46 ` Eli Zaretskii
2010-12-13 14:33 ` Pedro Alves
2010-12-13 14:56 ` Phil Muldoon
2010-12-13 15:07 ` Pedro Alves
2010-12-13 20:45 ` Doug Evans
2010-12-13 21:02 ` Phil Muldoon
2010-12-14 3:31 ` Doug Evans
2010-12-14 17:18 ` Phil Muldoon
2010-12-14 17:28 ` Tom Tromey
2010-12-14 19:51 ` Phil Muldoon [this message]
2010-12-14 20:00 ` Phil Muldoon
2010-12-15 15:34 ` Phil Muldoon
2010-12-15 20:51 ` Tom Tromey
2011-01-27 12:44 ` Phil Muldoon
[not found] ` <AANLkTimi6ugruNAqUGHni8Kvkz+B5-s2aAkEoTY2D_gT@mail.gmail.com>
2011-01-27 21:40 ` Phil Muldoon
2011-01-28 10:42 ` Tom Tromey
2010-12-15 16:21 ` Doug Evans
2010-12-15 20:57 ` Tom Tromey
2010-12-21 17:33 ` Doug Evans
2010-12-21 20:02 ` Tom Tromey
2010-12-22 16:34 ` Doug Evans
2010-12-22 17:35 ` Tom Tromey
2010-12-28 5:53 ` Doug Evans
2011-01-05 18:35 ` Tom Tromey
2011-01-05 20:23 ` Phil Muldoon
2011-01-09 20:32 ` Doug Evans
2010-12-14 17:46 ` Pedro Alves
2010-12-14 16:35 ` Tom Tromey
2010-12-14 17:02 ` Phil Muldoon
2010-12-14 17:48 ` Tom Tromey
2010-12-14 16:42 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3mxo8uo9g.fsf@redhat.com \
--to=pmuldoon@redhat.com \
--cc=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox