This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Add an evaluation function hook to Python breakpoints.
- From: Eli Zaretskii <eliz at gnu dot org>
- To: pmuldoon at redhat dot com
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 13 Dec 2010 17:07:40 +0200
- Subject: Re: [patch] Add an evaluation function hook to Python breakpoints.
- References: <m38vztlr2r.fsf@redhat.com> <8362uxiwmc.fsf@gnu.org> <m3bp4p686y.fsf@redhat.com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> From: Phil Muldoon <pmuldoon@redhat.com>
> Cc: gdb-patches@sourceware.org
> Date: Mon, 13 Dec 2010 14:47:33 +0000
>
> +class MyBreakpoint (gdb.Breakpoint):
> + def evaluate (self):
> + inf_val = gdb.parse_and_eval("foo")
> + if inf_val == 3:
> + return True
> + return False
>
> There are two scenarios where the breakpoints would be executed. The first
> is where you would end up instantiating two instances of the above
> breakpoint at the same location:
>
> python bp1 = MyBreakPoint("myfile.c:42")
> python bp2 = MyBreakpoint("myfile.c:42", internal=True)
So I would rephrase the text in question like this:
If this function is defined in a sub-class of @code{gdb.Breakpoint},
it will be called when the inferior reaches any breakpoint which
instantiates that sub-class.
Does this describe correctly what will happen?
> >> + The @code{evaluate} function should not
> >> +attempt to influence the state of the inferior (e.g., step) or
> >> +otherwise alter its data.
> >
> > Sounds like a non-trivial limitation; is it really necessary?
>
> I mentioned it as it was a non-trivial limitation? It is something the user
> should not do in the evaluate function. The most pressing reason is
> that there may be other breakpoints to be checked at that location so
> the state of the inferior should remain. The other is it is just bad
> business influencing the inferior position (i.e., stepping) when
> breakpoint evaluation is being performed.
We allow that from the CLI, FWIW.
> This is all well and good, but we cannot prevent the user from doing
> it; just tell them it is very bad idea. ;)
But if there's only one breakpoint at that location, there doesn't
seem to be any reasons to disallow this, right?
Anyway, this is not really related to the manual; if the modified text
above is okay with you, the patch for the manual is approved.
Thanks.