Re: [patch 3/3] bpstat_what removal [rediff]

[Pedro Alves <pedro at codesourcery dot com>]

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