This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 3/3] bpstat_what removal [rediff]
On Friday 18 June 2010 15:09:36, Jan Kratochvil wrote:
> There is missing and planned "new invisible breakpoints, with Python code
> attached" stated in:
> Tom Tromey: Re: [patch 3/3] bpstat_what removal [rediff]
> http://sourceware.org/ml/gdb-patches/2010-06/msg00376.html
>
> which can happen for (after re-hits start to be prevented):
> call_func_without_debuginfo ();
> line_with_python_invisible_breakpoint;
>
>
> > let's put thread event breakpoints and other kind of event breakpoints we'll
> > come up with, or even gdb side tracepoints in the mix.
>
> I assume you mean the case I have described now above.
Yes, those too. By gdb side tracepoints, I mean tracepoints that are
all handled by gdb core, with regular software breakpoint locations,
instead of relying on the target backend to implement them. Conceptually,
I think those python breakpoints, gdb side tracepoints, solib-, jit- and
thread- event breakpoints are all pretty much the same in infrun's perpective.
When they're hit, some callback is called, which does its own thing, and
returns one of "I cause a stop", or "I don't cause a stop, step over me and
let the inferior carry on doing what it was doing",
or "I don't cause a stop, and I'm now gone, so no need to step over me.".
Those python breakpoints sounds a lot like tracepoints to me, and goes
in line with what we've discussed before that "tracepoint" as more of an
attribute feeling an breakpoint-kind feeling.
Actually user breakpoints are pretty much the same too, if you consider that
the callback in question something like bpstat_check_breakpoint_conditions.
Anyways, there's clearly a distinction between infrun specific breakpoints,
and all other kinds of breakpoints.
--
Pedro Alves